caml-list - the Caml user's mailing list
 help / color / mirror / Atom feed
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

  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;
as well as URLs for NNTP newsgroup(s).