From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: X-Original-To: caml-list@sympa.inria.fr Delivered-To: caml-list@sympa.inria.fr Received: from mail3-relais-sop.national.inria.fr (mail3-relais-sop.national.inria.fr [192.134.164.104]) by sympa.inria.fr (Postfix) with ESMTPS id 4AFFE7EEBF for ; Wed, 19 Aug 2015 13:54:15 +0200 (CEST) Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of oliver@first.in-berlin.de) identity=pra; client-ip=192.109.42.8; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="oliver@first.in-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of oliver@first.in-berlin.de) identity=mailfrom; client-ip=192.109.42.8; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="oliver@first.in-berlin.de"; x-conformance=sidf_compatible Received-SPF: None (mail3-smtp-sop.national.inria.fr: no sender authenticity information available from domain of postmaster@einhorn.in-berlin.de) identity=helo; client-ip=192.109.42.8; receiver=mail3-smtp-sop.national.inria.fr; envelope-from="oliver@first.in-berlin.de"; x-sender="postmaster@einhorn.in-berlin.de"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: A0ACAQD4bdRVnAgqbcBdg29pBoMfqWuSOoV7AoFCTAEBAQEBARIBAQEBAQgLCQkhLoQjAQEBAwEjBBE2EAsLGAICCQ8OAgIhJBIZEgiHfwMKCAQJuUeQNQMKhWMggSKJLoEDgk+CNgyCaYFDBYVsDIZoiEOFBIV8gWoHS3tGhluKD4NPgi6BOoJlgUBvgkwBAQE X-IPAS-Result: A0ACAQD4bdRVnAgqbcBdg29pBoMfqWuSOoV7AoFCTAEBAQEBARIBAQEBAQgLCQkhLoQjAQEBAwEjBBE2EAsLGAICCQ8OAgIhJBIZEgiHfwMKCAQJuUeQNQMKhWMggSKJLoEDgk+CNgyCaYFDBYVsDIZoiEOFBIV8gWoHS3tGhluKD4NPgi6BOoJlgUBvgkwBAQE X-IronPort-AV: E=Sophos;i="5.15,709,1432591200"; d="scan'208";a="143158664" Received: from einhorn.in-berlin.de ([192.109.42.8]) by mail3-smtp-sop.national.inria.fr with ESMTP/TLS/DHE-RSA-AES256-SHA; 19 Aug 2015 13:53:46 +0200 X-Envelope-From: oliver@first.in-berlin.de X-Envelope-To: Received: from localhost (yak.in-berlin.de [192.109.42.109]) by einhorn.in-berlin.de (8.14.4/8.14.4/Debian-4) with ESMTP id t7JBrj8p014228 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Wed, 19 Aug 2015 13:53:45 +0200 Received: from x55b2016a.dyn.telefonica.de (x55b2016a.dyn.telefonica.de [85.178.1.106]) by webmail.in-berlin.de (Horde Framework) with HTTP; Wed, 19 Aug 2015 13:53:45 +0200 Date: Wed, 19 Aug 2015 13:53:45 +0200 Message-ID: <20150819135345.Horde.2Xe64AoMhxMNDYvna8zfvUt@webmail.in-berlin.de> From: Oliver Bandel To: caml-list@inria.fr References: <20150819004103.Horde.gmnxtcrVOwNtWht0UpT4DzE@webmail.in-berlin.de> <00A7715E-A042-4847-89F4-BA6F8AF20662@metastack.com> In-Reply-To: User-Agent: Horde Application Framework 5 Content-Type: text/plain; charset=utf-8; format=flowed; DelSp=Yes MIME-Version: 1.0 Content-Disposition: inline Subject: Re: [Caml-list] Simple exception - different behaviour between toplevel and compiled Hello, thanks to all, who answered. It made me clear, why the toplevel knows more then the compiled versions. For functions like Printexc.register_printer I wondered, why they are there... who would ever need them? Now they make sense to me. :-) And now I think about... possibly using exceptions and exception printers more usually - not just as a last resort - and more sophisticated - not just "exceptional" minimalistic messages - might make the code becoming better. Ciao, Oliver Zitat von Gabriel Scherer (Wed, 19 Aug 2015 07:35:13 +0200) > To Arthur's excellent answer, one can add that you can register > user-defined exception printers to batch programs (this does not > affect the toplevel): > > $ cat test.ml > exception Foo of (int * int) > > let () = Printexc.register_printer (function > | Foo (a, b) -> > Some (Printf.sprintf "Foo (%d, %d), with best regards" a b) > | _ -> None > ) > > let v = (1, 2) > let () = raise (Foo v) > > $ ocamlc -o test test.ml && ./test > Fatal error: exception Foo (1, 2), with best regards > > On Wed, Aug 19, 2015 at 2:06 AM, Arthur Wendling > wrote: >>> exception A of int * int >> >> This is an exception with two arguments. >> >>> exception B of (int*int) >> >> This is an exception with a single argument, which is a product of two >> values. So the parenthesis actually matters: >> >> # fun x -> A x ;; >> Error: The constructor A expects 2 argument(s), >> but is applied here to 1 argument(s) >> # fun x -> B x ;; >> - : int * int -> exn = >> >> I agree that the syntax is a bit surprising, since we are used to ignore >> extra parenthesis. >> >> Anyway, now, regarding the output of the interpreter/compiler: >> - A of int * int is printable by both, because the runtime can guess that >> the two arguments are integers (because they aren't pointers.) >> - B of (int * int) is only printed correctly by the interpreter, because it >> keeps the source information. The compiler erases all that, so the runtime >> only sees a single argument, that contains two ints, but it doesn't know how >> to display it: it could be something else than a tuple from the point of >> view of the user (like a record { x : int ; y : int }, but the names x,y >> have been forgotten, so the runtime representation is identical to (int * >> int)). >> >> >> On Wed, Aug 19, 2015 at 1:32 AM, David Allsopp >> wrote: >>> >>> > On 19 Aug 2015, at 00:41, Oliver Bandel >>> > 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 >>> >>> -- >>> Caml-list mailing list. Subscription management and archives: >>> https://sympa.inria.fr/sympa/arc/caml-list >>> Beginner's list: http://groups.yahoo.com/group/ocaml_beginners >>> Bug reports: http://caml.inria.fr/bin/caml-bugs >> >> > > -- > Caml-list mailing list. Subscription management and archives: > https://sympa.inria.fr/sympa/arc/caml-list > Beginner's list: http://groups.yahoo.com/group/ocaml_beginners > Bug reports: http://caml.inria.fr/bin/caml-bugs