Re: Decorating exceptions with backtrace information

Michael Sloan <[email protected]>
Newsgroups gmane.comp.lang.haskell.ghc.devel,gmane.comp.lang.haskell.glasgow.user
Message-ID <CAEDDsWfeF4Ha6EYk1kHK+fDN49aGYcoQMAuFTxFihUonNWLgLw@mail.gmail.com>
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 <[email protected]> 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
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
>

_______________________________________________
ghc-devs mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.