Re: [Caml-list] ANN: exn-source - exception backtraces with source code printing

[Gabriel Scherer <gabriel.scherer@gmail.com>]

[-- Attachment #1: Type: text/plain, Size: 2356 bytes --]

> 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/
>
>

[-- Attachment #2: Type: text/html, Size: 3183 bytes --]