Decorating exceptions with backtrace information

Michael Sloan mgsloan at gmail.com
Thu May 7 22:56:22 UTC 2020


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.

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.

-Michael

On Thu, May 7, 2020 at 3:55 PM Ben Gamari <ben at well-typed.com> wrote:

>
> Hi everyone,
>
> After a nice discussion on IRC about the unfortunate state of error
> reporting in Haskell, I felt compelled to write down some long-lingering
> thoughts regarding backtraces on exceptions. The result is GHC proposal
> #330 [1]. I think the approach is viable and perhaps even
> straightforward. I have the sketch of an implementation here [2].
>
> Please have a look at the proposal and leave your comments. If there is
> consensus it is possible that we could have this done for 8.12.
>
> Cheers,
>
> - Ben
>
>
> [1] https://github.com/ghc-proposals/ghc-proposals/pull/330
> [2] https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3236
> _______________________________________________
> ghc-devs mailing list
> ghc-devs at haskell.org
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-devs/attachments/20200507/d07a1dfb/attachment.html>


More information about the ghc-devs mailing list