[MLton] MLton.Exn.setTopLevelHandler

[Matthew Fluet]

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