Decorating exceptions with backtrace information

[Ben Gamari]

Michael Sloan <mgsloan at gmail.com> writes:

> Thanks so much for making a proposal for this, Ben!!  It's great to see
> progress here.
>
> I'm also glad that there is now a proposal process.  I made a fairly
> similar proposal almost exactly 5 years ago to the libraries list -
> https://mail.haskell.org/pipermail/libraries/2015-April/025471.html - but
> without the subtlety of particular backtrace representations.  Skimming the
> ensuing thread may still be informative.
>
Thanks for the reference, Michael! My feeling is that the proposal in
that thread is a bit too dynamic. That being said, I can see the
argument for wanting, for instance, a robust way to determine that an
exception is asynchronous.

> In particular, there is one thing I would like to highlight from that old
> proposal.  I think it'd be good to have a standard way to represent a chain
> of exceptions, and build this into `catch` and `finally`.  Python and Java
> both have a mechanism for this, and both refer to it as a "cause"
> exception.  When an exception is thrown during exception handling, the
> exception being handled is preserved as its "cause".  I find this mechanism
> to be incredibly useful in Java, it has made the underlying issue much
> clearer in many cases, and in other cases at least provides helpful
> context.  I have no doubt such a mechanism would have saved me many hours
> of debugging exceptions in Haskell systems I've worked on in the past.
>
> I considered commenting about that directly on the proposal, but I figure
> this is a better place to suggest expanding the scope of the change :) .
> Totally understandable if you want to keep this proposal focused on
> stacktraces, but I think it'd be good to consider this as a potential
> future improvement.
>
Indeed I can see the point. I'll keep this point in the back of my mind.
I'm not eager to further expand the scope of the proposal at the moment,
but we should be certain that the backtrace design doesn't
unintentionally close the door to this use-case.

However, one question I would have is whether the exception-chaining
use-case *needs* to be handled in SomeException. For instance, you could
rather leave this to user code. You might even give this pattern a
typeclass. For instance,

    class HasChainedException e where
        getChainedException :: e -> Maybe SomeException

    data MyException = MyException { causedBy :: SomeException }

    instance HasChainedException MyException where
        getChainedException = causedBy

Cheers,

- Ben
-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 487 bytes
Desc: not available
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200511/2184b1df/attachment.sig>