[MLton] MLton.Exn.setTopLevelHandler
Matthew Fluet
fluet at tti-c.org
Wed Jun 13 14:30:54 PDT 2007
Vesa Karvonen wrote:
> On 6/13/07, Matthew Fluet <fluet at tti-c.org> wrote:
>> Vesa Karvonen wrote:
>> > Is there some reason why functionality
>> > equivalent to Primitive.TopLevel.setHandler is not exposed?
>>
>> I don't see why not. I don't think it was clear why it would be useful.
>> Generally, wrapping a 'main' function with a "handle _ => ..." usually
>> accomplishes the same thing.
>
> Unless the evaluation of some top-level declaration (maybe in a
> library) raises an exception before the main is entered. So, it can
> be useful to make it so that the required special handler is installed
> as the first thing when necessary. In some cases outputting to stderr
> may not be enough or even work.
I consider that a poor library implementation, but I can see it could
happen. The other difficulty is that the code to implement the special
handler needs to be executed before installing the handler, so you need
to avoid relying on your exception raising library in the implementation
of your handler. If you simply rely on the Basis Library, you should be
o.k.
>> I think the patch looks fine. There is one oddity --
>> MLton.Exn.topLevelHandler is equivalent to the default top-level
>> handler, rather than the dynamically installed top-level handler. I
>> don't think that is bad, but just a curiosity.
>
> Good point.
>
>> We might rename
>> MLton.Exn.topLevelHandler to something that doesn't suggest that it is
>> the 'getter' for MLton.Exn.setTopLevelHandler.
>
> MLton.Exn.defaultTopLevelHandler ?
That sounds better. One could also have 'MLton.Exn.topLevelHandler'
that does behave as the dynamically installed top-level handler. That
is, have
val setTopLevelHandler: (exn -> unit) -> unit
val getTopLevelHandler: unit -> (exn -> unit)
val topLevelHandler: exn -> 'a
val defaultTopLevelHandler: exn -> 'a
More information about the MLton
mailing list