Proposal: offer a way to augment call stacks

[Bardur Arantsson]

On 2018-03-15 00:16, David Feuer wrote:
> Faking up a way to add this functionality without modifying GHC or
> base library code, I ran into several issues:
> 
[--snip--]
> 2. There was no obvious way to deal with exceptions thrown evaluating
> call stack notes themselves.
> 
[--snip--]
> 
> For 2, we need to discuss how to handle this situation. One option is
> to catch the first exception, abort the process of printing the call
> stack, and then rethrow the exception. Another option is to try to get
> as much of the stack trace as possible before aborting; this gets a
> bit hairy. I don't know what other options there might be. Most of
> these options involve some modifications to the implementation of
> error.

When reading your initial proposal, I actually wondered about this --
could the model from Java's Throwable be used here?

Every Throwable (think Exception) in Java has an attached list of
so-called suppressed exceptions (plus stack traces). This allows one to
-- if not handle, exactly -- at least avoid losing exception information
when an exception is thrown during exception handling. Generally, one
exception is still regarded as the "primary" exception and is the only
one that's actually matched by "catch" clauses, but since Haskell is a
lot more flexible than Java wrt. catch, I don't think this necessarily
need to be a limitation for a Haskell implementation of the same
concept. Obviously, the "standard" catch mechanism would remain as-is,
regardless just to avoid breaking backward compatibility.

I have no idea what kind of performance impact this would have or how
hard it would be to do, but AFAICT it would "solve" your problem here
and it would also help in various cases of "nested" exception handling
where one is forced to through information away.

Regards,