From: David Allsopp <dra-news@metastack.com>
To: Oliver Bandel <oliver@first.in-berlin.de>
Cc: "caml-list@inria.fr" <caml-list@inria.fr>
Subject: Re: [Caml-list] Simple exception - different behaviour between toplevel and compiled
Date: Tue, 18 Aug 2015 23:32:06 +0000 [thread overview]
Message-ID: <00A7715E-A042-4847-89F4-BA6F8AF20662@metastack.com> (raw)
In-Reply-To: <20150819004103.Horde.gmnxtcrVOwNtWht0UpT4DzE@webmail.in-berlin.de>
> On 19 Aug 2015, at 00:41, Oliver Bandel <oliver@first.in-berlin.de> wrote:
>
> Hello,
>
>
> using the attached files (executing testexc,bash)
> I got different results between toplevel and compiled:
>
> =====================================================
> Testcase A
> exception A of int * int
> let _ = raise ( A(3,4) )
> Exception: A (3, 4).
> Fatal error: exception Exca.A(3, 4)
> Fatal error: exception Exca.A(3, 4)
> Testcase B
> exception B of (int*int)
> let _ = raise ( B(3,4) )
> Exception: B (3, 4).
> Fatal error: exception Excb.B(_)
> Fatal error: exception Excb.B(_)
> =====================================================
>
> So just adding parantheses in a definition of an exception
> yields in these differing results, with not-shown exception-values.
>
> IMHO looks like a case for the bugtracker...
There's no requirement for the toplevel and the compilers to behave the same way for reporting the exception. The output, for example, also differs in the way the exception message is formatted, there's no 'Fatal error:' and so on - do you want that to be a bug too?
The toplevel has access to typing information which is not available to ocamlc/ocamlopt (the runtime only knows the name of the exception - beyond that, it's just presented with a standard variant block). I haven't got a compiler to hand, but I think you'll also see differences if you use a variant instead of numbers (ocaml will display the constructor name, the compilers will display its constructor number) and I think you'll also see the same output as the compilers if you compile excb.cmo and then #load it in the toplevel.
It's not normal to want to terminate your compiled program with an uncaught exception, hence the simpler default exception printer in compiled code. If you really want the exception printed accurately, you can register a printer (see Printexc.register_printer).
David
next prev parent reply other threads:[~2015-08-18 23:32 UTC|newest]
Thread overview: 8+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-08-18 22:41 Oliver Bandel
2015-08-18 23:32 ` David Allsopp [this message]
2015-08-19 0:06 ` Arthur Wendling
2015-08-19 5:35 ` Gabriel Scherer
2015-08-19 11:53 ` Oliver Bandel
2015-08-19 11:16 ` Oliver Bandel
2015-08-19 11:22 ` Mr. Herr
2015-08-19 11:26 ` Oliver Bandel
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=00A7715E-A042-4847-89F4-BA6F8AF20662@metastack.com \
--to=dra-news@metastack.com \
--cc=caml-list@inria.fr \
--cc=oliver@first.in-berlin.de \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox