From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail2-relais-roc.national.inria.fr (mail2-relais-roc.national.inria.fr [192.134.164.83]) by sympa.inria.fr (Postfix) with ESMTPS id 3BDC17F02D for ; Sun, 19 Oct 2014 21:06:16 +0200 (CEST) Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of gabriel.scherer@gmail.com) identity=pra; client-ip=209.85.214.180; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible Received-SPF: Pass (mail2-smtp-roc.national.inria.fr: domain of gabriel.scherer@gmail.com designates 209.85.214.180 as permitted sender) identity=mailfrom; client-ip=209.85.214.180; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="gabriel.scherer@gmail.com"; x-conformance=sidf_compatible; x-record-type="v=spf1" Received-SPF: None (mail2-smtp-roc.national.inria.fr: no sender authenticity information available from domain of postmaster@mail-ob0-f180.google.com) identity=helo; client-ip=209.85.214.180; receiver=mail2-smtp-roc.national.inria.fr; envelope-from="gabriel.scherer@gmail.com"; x-sender="postmaster@mail-ob0-f180.google.com"; x-conformance=sidf_compatible X-IronPort-Anti-Spam-Filtered: true X-IronPort-Anti-Spam-Result: Aj0BALIKRFTRVda0m2dsb2JhbABbg2FYBIMCxyGBbIdSAoEHBxYBEQEBAQEBBgsLCRQuhAIBAQEDARIRBBkBGx0BAwELBgUHBA0qAgIiAREBBQEcBhMIGogIAQMJCJ8vboswgXKDEIgQChknDWeFSgEBAQEGAQEBAQEXAQUOkEMHgneBVAWTB4M/hxOBMDyNX4JWggwYKYNogUU7L4JLAQEB X-IPAS-Result: Aj0BALIKRFTRVda0m2dsb2JhbABbg2FYBIMCxyGBbIdSAoEHBxYBEQEBAQEBBgsLCRQuhAIBAQEDARIRBBkBGx0BAwELBgUHBA0qAgIiAREBBQEcBhMIGogIAQMJCJ8vboswgXKDEIgQChknDWeFSgEBAQEGAQEBAQEXAQUOkEMHgneBVAWTB4M/hxOBMDyNX4JWggwYKYNogUU7L4JLAQEB X-IronPort-AV: E=Sophos;i="5.04,749,1406584800"; d="scan'208";a="101916910" Received: from mail-ob0-f180.google.com ([209.85.214.180]) by mail2-smtp-roc.national.inria.fr with ESMTP/TLS/RC4-SHA; 19 Oct 2014 21:06:15 +0200 Received: by mail-ob0-f180.google.com with SMTP id va2so2867743obc.11 for ; Sun, 19 Oct 2014 12:06:14 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc:content-type; bh=7MbnC4r6EuKz1FeBBilUYsPf5b+8jZdovLco6poZxgw=; b=tUjGKTBn1T7bm/E4EWygBs4YhnXc0EIREPX1ZGMVQhwHFAUn+kXkarrSmws6HOYN0j 7qpD1bR3w8BMijS5B5U4FbKr6iD0LT6a4sLKgR1R93IthzPn08JTlCyiIq8P6CmNDril rl7JgfguexsbsEIizJuJU2cCQGqj4AEFYPhpYQSum1zq3b6hnYAOCzwyzyCZxJmXLtoW XLXNVZnANnmYg/8lCKi4vhaTH5tllXGrChjwnsJX83BKPy7MAubJc6A+Mgqot0QQMXqK SoJcBwhF82CyzhDPJ9VEY06KnTkeWpLRpcyjMbU5NZDHNciUK2UGiyHWvIfl7iSIhd1n drRQ== X-Received: by 10.182.95.9 with SMTP id dg9mr3162391obb.44.1413745574346; Sun, 19 Oct 2014 12:06:14 -0700 (PDT) MIME-Version: 1.0 Received: by 10.76.105.196 with HTTP; Sun, 19 Oct 2014 12:05:33 -0700 (PDT) In-Reply-To: <54440936.3010001@coherentgraphics.co.uk> References: <5443FCE6.50206@coherentgraphics.co.uk> <54440936.3010001@coherentgraphics.co.uk> From: Gabriel Scherer Date: Sun, 19 Oct 2014 21:05:33 +0200 Message-ID: To: John Whitington Cc: "caml-list@inria.fr" Content-Type: multipart/alternative; boundary=089e01538a12c3056c0505cb4ac5 Subject: Re: [Caml-list] ANN: exn-source - exception backtraces with source code printing --089e01538a12c3056c0505cb4ac5 Content-Type: text/plain; charset=UTF-8 > perhaps it's just in need of clarification in the documentation. My understanding is that uncaught exception raised by the handler are dropped/ignored. Would you mind creating a mantis issue ( http://caml.inria.fr/mantis/ ) so that we can discuss improving the documentation there? Note that a way to side-step this issue entirely would be for your API to provide something in the style of Printexc.print handle : ('a -> 'b) -> 'a -> 'b that handles any exception raised by the function application. Users would be able to call this explicitly around their main processing loop (which is the place where they often already handle exception-handling) instead of delegating to a possibly-fragile mutable final handler. My understanding is that exn-source currently operates by a side-effect at link-time. I would rather have the choice between an explicit (unit -> unit) registration function, and a side-effect-free handling function as above. On Sun, Oct 19, 2014 at 8:55 PM, John Whitington < john@coherentgraphics.co.uk> wrote: > Hi Gabriel, > > Gabriel Scherer wrote: > >> > (we can't use exceptions at all inside a backtrace handler, for >> example) >> >> I'm a bit surprised by this. Part of the point of reifying traces into >> datatypes (raw_backtrace, backtrace_slot) was to make them persistent. >> set_uncaught_exception_handler is passed a raw trace that should not be >> mutated by raising new exceptions. What breaks if you use exceptions >> inside a backtrace handler? >> > > To quote the documentation for set_uncaught_exception_handler: "If fn > raises an exception, it is ignored." > > This is a bit ambiguous -- it might mean > > a) The uncaught exception handler you register won't get called from > inside itself in the case of an uncaught exception. Nor will any such > exceptions be handled by the standard exception handler; or > > b) Exceptions in the handler literally have no effect. > > I've done a little test just now, and it seems to be (a), so perhaps it's > just in need of clarification in the documentation. > > (It might be nice to have, for development, an option to have the default > exception handler remain active, so it reports any exceptions escaping from > the user-installed exception handler). > > > Thanks, > > -- > John Whitington > Director, Coherent Graphics Ltd > http://www.coherentpdf.com/ > > --089e01538a12c3056c0505cb4ac5 Content-Type: text/html; charset=UTF-8 Content-Transfer-Encoding: quoted-printable
> perhaps it's just in nee= d of clarification in the documentation.

My understanding is that un= caught exception raised by the handler are dropped/ignored.
Would you mi= nd creating a mantis issue ( http:= //caml.inria.fr/mantis/ ) so that we can discuss improving the document= ation there?

Note that a way to side-step this issue entirely = would be for your API to provide something in the style of Printexc.print
=C2=A0 handle : ('a -> 'b) -> 'a -> '= ;b
that handles any exception raised by the function application. = Users would be able to call this explicitly around their main processing lo= op (which is the place where they often already handle exception-handling) = instead of delegating to a possibly-fragile mutable final handler.

<= /div>My understanding is that exn-source currently operates by a side-effec= t at link-time. I would rather have the choice between an explicit (unit -&= gt; unit) registration function, and a side-effect-free handling function a= s above.

On Sun, Oct= 19, 2014 at 8:55 PM, John Whitington <john@coherentgraphics.co.= uk> wrote:
Hi Gabriel,

Gabriel Scherer wrote:
=C2=A0> (we can't use exceptions at all inside a backtrace handler, = for example)

I'm a bit surprised by this. Part of the point of reifying traces into<= br> datatypes (raw_backtrace, backtrace_slot) was to make them persistent.
set_uncaught_exception_handler is passed a raw trace that should not be
mutated by raising new exceptions. What breaks if you use exceptions
inside a backtrace handler?

To quote the documentation for set_uncaught_exception_handler: "= ;If fn raises an exception, it is ignored."

This is a bit ambiguous -- it might mean

a) The uncaught exception handler you register won't get called from in= side itself in the case of an uncaught exception. Nor will any such excepti= ons be handled by the standard exception handler; or

b) Exceptions in the handler literally have no effect.

I've done a little test just now, and it seems to be (a), so perhaps it= 's just in need of clarification in the documentation.

(It might be nice to have, for development, an option to have the default e= xception handler remain active, so it reports any exceptions escaping from = the user-installed exception handler).


Thanks,

--
John Whitington
Director, Coherent Graphics Ltd
http://www.cohere= ntpdf.com/


--089e01538a12c3056c0505cb4ac5--