Open mpickering opened 3 weeks ago
This sounds reasonable to me. Would you be willing to open a PR with an implementation?
I think the patch is more complicated than some CPP, as the interface for exceptions
should allow users to also control propagation behaviour?
To clarify, are you proposing that exceptions
should offer a new API that allows deciding how exceptions are propagated? Or that it already does this?
If it's the latter, I'm not sure what part of the API does this. If it's the former, then I could use your help in figuring out what the API should look like, as this is new territory for me.
The implementation and API of exceptions library should be modified to take into account the exception annotation propagation behaviour of
catch
.CLC Proposal: https://github.com/haskell/core-libraries-committee/issues/202 GHC MR: https://gitlab.haskell.org/ghc/ghc/-/merge_requests/13302
In the next version of base there will be two versions of
catch
catch
- Annotate exceptions thrown in a handler with an annotation which records the exception which caused the handler to be invoked.catchNoPropagate
- The same behaviour ascatch
before 9.12.In general it is better for exception utilities to be implemented in terms of
catchNoPropagate
, as the user does not care about the internal workings of utilities such asonException
. They just want the backtrace of theWhen you have multiple layers of error handling, without further action the call stacks will be quite large and messy. The rethrow in
onException
andbracket
adds much additional noise to the error.