Done. http://caml.inria.fr/mantis/view.php?id=6619
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.
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.