#330: Decorate exceptions with backtrace information, rec: accept

Dear Committee, Ben Gamari has proposed #330 "Decorate exceptions with backtrace information". Read it here: https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exc... The proposal attaches contextual information to thrown exceptions. This information includes (but is not limited to) backtraces, making it possible to debug uncaught exceptions more effectively. This is a very nuanced change, since it modifies SomeException, throw, catch, and other exception-related definitions whose use is extremely widespread. We might end up affecting our users in unexpected ways. Because of that, I ask the committee to review the proposal with the appropriate amount of care. I am recommending acceptance because adding observability to our programs is an important part of developer ergonomics. From the proposal discussion, I have got the impression that there are numerous commercial users who would benefit from this. Please take a look at the proposal text and share your thoughts either here or directly on GitHub. - Vlad

Strong accept from me. I left one question about the backtrace collection defaults on GitHub. On Mon, Mar 6, 2023, at 08:44, Vladislav Zavialov wrote:
Dear Committee,
Ben Gamari has proposed #330 "Decorate exceptions with backtrace information". Read it here:
https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exc...
The proposal attaches contextual information to thrown exceptions. This information includes (but is not limited to) backtraces, making it possible to debug uncaught exceptions more effectively.
This is a very nuanced change, since it modifies SomeException, throw, catch, and other exception-related definitions whose use is extremely widespread. We might end up affecting our users in unexpected ways. Because of that, I ask the committee to review the proposal with the appropriate amount of care.
I am recommending acceptance because adding observability to our programs is an important part of developer ergonomics. From the proposal discussion, I have got the impression that there are numerous commercial users who would benefit from this.
Please take a look at the proposal text and share your thoughts either here or directly on GitHub.
- Vlad _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

I have read the proposal, but I don't feel in a position to offer a
well-informed judgement about it. It proposes a lot of specific changes to
a part of GHC's ecosystem that I'm not familiar with.
If we turn out to lack sufficient expertise on the steering committee,
maybe we should consult some plausible external experts? Or maybe we have
enough on the committee. I'm not sure.
TL;DR: I should be considered a "don't know". But the goal looks plausible
to me.
Other committee members: please express your views.
Simon
On Mon, 6 Mar 2023 at 13:44, Vladislav Zavialov
Dear Committee,
Ben Gamari has proposed #330 "Decorate exceptions with backtrace information". Read it here:
https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exc...
The proposal attaches contextual information to thrown exceptions. This information includes (but is not limited to) backtraces, making it possible to debug uncaught exceptions more effectively.
This is a very nuanced change, since it modifies SomeException, throw, catch, and other exception-related definitions whose use is extremely widespread. We might end up affecting our users in unexpected ways. Because of that, I ask the committee to review the proposal with the appropriate amount of care.
I am recommending acceptance because adding observability to our programs is an important part of developer ergonomics. From the proposal discussion, I have got the impression that there are numerous commercial users who would benefit from this.
Please take a look at the proposal text and share your thoughts either here or directly on GitHub.
- Vlad _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

High-level we definitely want this, I added a couple of comments to the
GitHub thread to discuss details.
One slightly suboptimal aspect of the proposal is the use of implicit
parameters. The design in Section 8.2
https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exc...
seems much nicer and is only prevented by issues with pattern synonyms.
Couldn't we fix pattern synonyms so this would work?
Cheers
Simon
On Mon, 6 Mar 2023 at 13:44, Vladislav Zavialov
Dear Committee,
Ben Gamari has proposed #330 "Decorate exceptions with backtrace information". Read it here:
https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exc...
The proposal attaches contextual information to thrown exceptions. This information includes (but is not limited to) backtraces, making it possible to debug uncaught exceptions more effectively.
This is a very nuanced change, since it modifies SomeException, throw, catch, and other exception-related definitions whose use is extremely widespread. We might end up affecting our users in unexpected ways. Because of that, I ask the committee to review the proposal with the appropriate amount of care.
I am recommending acceptance because adding observability to our programs is an important part of developer ergonomics. From the proposal discussion, I have got the impression that there are numerous commercial users who would benefit from this.
Please take a look at the proposal text and share your thoughts either here or directly on GitHub.
- Vlad _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

Likewise: very supportive, a few holes that I'd like to address before
fully committing.
Contrary to Simon M, though, I think I prefer the implicit parameter design
to the pattern-synonym design.
On Thu, 9 Mar 2023 at 11:23, Simon Marlow
High-level we definitely want this, I added a couple of comments to the GitHub thread to discuss details.
One slightly suboptimal aspect of the proposal is the use of implicit parameters. The design in Section 8.2 https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exc... seems much nicer and is only prevented by issues with pattern synonyms. Couldn't we fix pattern synonyms so this would work?
Cheers Simon
On Mon, 6 Mar 2023 at 13:44, Vladislav Zavialov
wrote: Dear Committee,
Ben Gamari has proposed #330 "Decorate exceptions with backtrace information". Read it here:
https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exc...
The proposal attaches contextual information to thrown exceptions. This information includes (but is not limited to) backtraces, making it possible to debug uncaught exceptions more effectively.
This is a very nuanced change, since it modifies SomeException, throw, catch, and other exception-related definitions whose use is extremely widespread. We might end up affecting our users in unexpected ways. Because of that, I ask the committee to review the proposal with the appropriate amount of care.
I am recommending acceptance because adding observability to our programs is an important part of developer ergonomics. From the proposal discussion, I have got the impression that there are numerous commercial users who would benefit from this.
Please take a look at the proposal text and share your thoughts either here or directly on GitHub.
- Vlad _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On Thu, 9 Mar 2023 at 10:39, Arnaud Spiwack
Likewise: very supportive, a few holes that I'd like to address before fully committing.
Contrary to Simon M, though, I think I prefer the implicit parameter design to the pattern-synonym design.
Out of interest, why? Simon
On Thu, 9 Mar 2023 at 11:23, Simon Marlow
wrote: High-level we definitely want this, I added a couple of comments to the GitHub thread to discuss details.
One slightly suboptimal aspect of the proposal is the use of implicit parameters. The design in Section 8.2 https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exc... seems much nicer and is only prevented by issues with pattern synonyms. Couldn't we fix pattern synonyms so this would work?
Cheers Simon
On Mon, 6 Mar 2023 at 13:44, Vladislav Zavialov
wrote: Dear Committee,
Ben Gamari has proposed #330 "Decorate exceptions with backtrace information". Read it here:
https://github.com/bgamari/ghc-proposals/blob/stacktraces/proposals/0000-exc...
The proposal attaches contextual information to thrown exceptions. This information includes (but is not limited to) backtraces, making it possible to debug uncaught exceptions more effectively.
This is a very nuanced change, since it modifies SomeException, throw, catch, and other exception-related definitions whose use is extremely widespread. We might end up affecting our users in unexpected ways. Because of that, I ask the committee to review the proposal with the appropriate amount of care.
I am recommending acceptance because adding observability to our programs is an important part of developer ergonomics. From the proposal discussion, I have got the impression that there are numerous commercial users who would benefit from this.
Please take a look at the proposal text and share your thoughts either here or directly on GitHub.
- Vlad _______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
_______________________________________________ ghc-steering-committee mailing list ghc-steering-committee@haskell.org https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee

On Thu, 9 Mar 2023 at 12:52, Simon Marlow
Out of interest, why?
I'm not sure that I can quite say. The idea of annotations being somewhat implicitly passed, the symmetry with `HasCallStack`: it appeals to me. I guess it's not a very strong preference.

My questions have been addressed, I'm now content with the proposal.
On Thu, 9 Mar 2023 at 18:03, Arnaud Spiwack
On Thu, 9 Mar 2023 at 12:52, Simon Marlow
wrote: Out of interest, why?
I'm not sure that I can quite say. The idea of annotations being somewhat implicitly passed, the symmetry with `HasCallStack`: it appeals to me. I guess it's not a very strong preference.

Dear Committee,
Back in March I recommended to accept GHC Proposal #330 "Decorate
exceptions with backtrace information". It appears to me that we all agree
that the proposed change is a good idea. There were a couple of technical
suggestions that the author readily incorporated into the proposal text
(the most important addition: nested `WhileHandling` annotations). I've
skimmed the proposal one more time before writing this message and I find
that it is in a very good state now.
I'm about to declare it accepted, any last moment objections?
Vlad
On Fri, Mar 10, 2023 at 8:47 AM Arnaud Spiwack
My questions have been addressed, I'm now content with the proposal.
On Thu, 9 Mar 2023 at 18:03, Arnaud Spiwack
wrote: On Thu, 9 Mar 2023 at 12:52, Simon Marlow
wrote: Out of interest, why?
I'm not sure that I can quite say. The idea of annotations being somewhat implicitly passed, the symmetry with `HasCallStack`: it appeals to me. I guess it's not a very strong preference.

I marked #330 as accepted and merged it.
On Wed, May 24, 2023 at 1:20 PM Vladislav Zavialov
Dear Committee,
Back in March I recommended to accept GHC Proposal #330 "Decorate exceptions with backtrace information". It appears to me that we all agree that the proposed change is a good idea. There were a couple of technical suggestions that the author readily incorporated into the proposal text (the most important addition: nested `WhileHandling` annotations). I've skimmed the proposal one more time before writing this message and I find that it is in a very good state now.
I'm about to declare it accepted, any last moment objections?
Vlad
participants (5)
-
Arnaud Spiwack
-
Eric Seidel
-
Simon Marlow
-
Simon Peyton Jones
-
Vladislav Zavialov