[MLton-user] Lack of information with -const 'Exn.keepHistory true'

[Nicolas Bertolotti]

OK, thanks anyway.

The previous version we used (20030716) used a different mechanism to handle
the option '-exn-history true'. Though it was not perfect, we could manage
to hack our code and get more information by adding a bunch of "handle x =>
raise x" constructs in our code.

Unfortunately, this does not change anything with the new mechanism. 

Do you think there would be a similar construct we could use in order to
achieve the same result with the new mechanism ? (then we may find a
solution to apply it thanks to the defunctorizer we use).

Regards

Nicolas

> 
> 
> > But it still does not provide a location in my own code which could make
> it
> > easier to identify the path to the error. As a consequence, I'll need to
> > instrument my code in order to identify the appropriate location.
> 
> Yes, the exception history mechanism seems to have some issues with
> shallow call stacks.  For example, the following program produces no
> history:
> 
> fun doit () = raise Subscript
> val () = doit ()
> 
> However, the following does:
> 
> fun doit n = if n = 0 then raise Subscript else doit (n - 1)
> val () = doit 1
> 
> > I'm just trying to find an appropriate set of options I could use while
> > debugging in order to get as many information as possible in order to
> > identify the full path to a particular error.
> 
> I don't believe that there is any more that you can get out of the
> current version of the compiler.
>