<div dir="ltr">ben, could you please email the libraries list with this too? This seems like a core libraries / base change rather than a ghc-the-compiler change </div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020 at 6:57 PM Michael Sloan <<a href="mailto:mgsloan@gmail.com">mgsloan@gmail.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><div dir="ltr">Thanks so much for making a proposal for this, Ben!! It's great to see progress here.<div><br></div><div>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 - <a href="https://mail.haskell.org/pipermail/libraries/2015-April/025471.html" target="_blank">https://mail.haskell.org/pipermail/libraries/2015-April/025471.html</a> - but without the subtlety of particular backtrace representations. Skimming the ensuing thread may still be informative.</div><div><br></div><div>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.</div><div><br></div><div>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.</div><div><br></div><div>-Michael</div><div></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, May 7, 2020 at 3:55 PM Ben Gamari <<a href="mailto:ben@well-typed.com" target="_blank">ben@well-typed.com</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex"><br>
Hi everyone,<br>
<br>
After a nice discussion on IRC about the unfortunate state of error<br>
reporting in Haskell, I felt compelled to write down some long-lingering<br>
thoughts regarding backtraces on exceptions. The result is GHC proposal<br>
#330 [1]. I think the approach is viable and perhaps even<br>
straightforward. I have the sketch of an implementation here [2].<br>
<br>
Please have a look at the proposal and leave your comments. If there is<br>
consensus it is possible that we could have this done for 8.12.<br>
<br>
Cheers,<br>
<br>
- Ben<br>
<br>
<br>
[1] <a href="https://github.com/ghc-proposals/ghc-proposals/pull/330" rel="noreferrer" target="_blank">https://github.com/ghc-proposals/ghc-proposals/pull/330</a><br>
[2] <a href="https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3236" rel="noreferrer" target="_blank">https://gitlab.haskell.org/ghc/ghc/-/merge_requests/3236</a><br>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>
_______________________________________________<br>
ghc-devs mailing list<br>
<a href="mailto:ghc-devs@haskell.org" target="_blank">ghc-devs@haskell.org</a><br>
<a href="http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs" rel="noreferrer" target="_blank">http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs</a><br>
</blockquote></div>