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

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

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

>
> Done. http://caml.inria.fr/mantis/view.php?id=6619
>

Thanks! Having an issue really helps tracking that things get done.

there is one advantage to the current approach: no source code needs to be
> changed in the simplest case (just searching '.') - we just link exn-source
> in.
> [...]
> So perhaps I should make it build exn-source.cm(x)a and exn-source-easy.cm(x)a,
> and have two choices.
>

Indeed. exn-source-easy (or -autolink) could simply depend on the "clean
API" in the exn-source library, by being implemented as just
  let () = Exn_source.register ()

Then simply making sure to pass the flag -linkall when building that second
cma means that explicitly requiring it (in the build system) will enable
the feature.

On Sun, Oct 19, 2014 at 9:38 PM, John Whitington <
john@coherentgraphics.co.uk> wrote:

> Hi,
>
> Gabriel Scherer wrote:
>
>>  > 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?
>>
>
> Done. http://caml.inria.fr/mantis/view.php?id=6619
>
>  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.
>>
>
> Correct. Your suggestion would be much cleaner, but there is one advantage
> to the current approach: no source code needs to be changed in the simplest
> case (just searching '.') - we just link exn-source in.
>
> People won't want to necessarily ship code with exn-source linked in, and
> it's not nice to have to modify code between debug and release -- I like to
> try to have those differences all in the build system.
>
> So perhaps I should make it build exn-source.cm(x)a and exn-source-easy.cm(x)a,
> and have two choices.
>
> Thanks.
>
>
> --
> John Whitington
> Director, Coherent Graphics Ltd
> http://www.coherentpdf.com/
>
>

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