[ghc-steering-committee] #330: Decorate exceptions with backtrace information, rec: accept

Arnaud Spiwack arnaud.spiwack at tweag.io
Thu Mar 9 10:39:16 UTC 2023


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 <marlowsd at gmail.com> 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-exception-backtraces.rst#82exception-hierarchy-design-alternative-two>
> 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 <vlad.z.4096 at gmail.com>
> 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-exception-backtraces.rst
>>
>> 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 at haskell.org
>> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>>
> _______________________________________________
> ghc-steering-committee mailing list
> ghc-steering-committee at haskell.org
> https://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-steering-committee
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.haskell.org/pipermail/ghc-steering-committee/attachments/20230309/750ac939/attachment.html>


More information about the ghc-steering-committee mailing list