Re: Decorating exceptions with backtrace information

Michael Sloan <[email protected]> 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

_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users

-----BEGIN PGP SIGNATURE-----

iQEzBAEBCAAdFiEEmwpsh4C13+CdDZRjcVB86Evun78FAl65c7YACgkQcVB86Evu
n7/qPggA3gROeRWaDGiV3KZhjlK1hRxFsRoV7Z/IlfA28DcQ3nQ8TLJ5I0br5Jt+
XQc8wi0zvjWfUFjo6IweW84ZXRYJUgH54P6QKXKSqT3a04PzyG56K7ASgsU6K9BM
Ee4eNNc5kq4ANCBGe1Xb8juXGlfEJxKKTInRinRv21hYgHzvdHUj3nftQeos8pkk
8gj+rG64ZVu4Loy/lGbGyWzEhYPABN6zJ2t+MAp6ePEMYJN9Cd4oZhXIis9uqflK
jQxK5EzPPkaCnt3yqSiqlH9T5cnDaDElhouTw82/ZtGC5hlfcHRTgWunQjXvmVH7
WR5eIfZ0pSk72ZOqvm8S71IBKm1SvA==
=XPpo
-----END PGP SIGNATURE-----