Re: Decorating exceptions with backtrace information

This reminds me a joke to put it in a humorous way:

> A software QA engineer walks into a bar. He orders a beer. Orders 0 beers. Orders 99999999999 beers. Orders a lizard. Orders -1 beers.
> First real customer walks in and asks where the bathroom is. The bar bursts into flames, killing everyone.

LOL,
Compl

> On 2020-05-09, at 02:18, Ben Gamari <[email protected]> wrote:
> 
> Henning Thielemann <[email protected]> writes:
> 
>> On Fri, 8 May 2020, Niklas Hambüchen wrote:
>> 
>>> On 5/8/20 7:32 PM, Henning Thielemann wrote:
>>> 
>>>> Can someone please give me examples where current state lacks
>>> 
>>> * Currently stack traces are not printed, so users cannot forward them 
>>> to the developer, even if both the users and the developers would like 
>>> that.
>> 
>> We are talking about the HasCallStack stack traces, yes?
>> How is their emission addressed by extending exceptions with stack
>> traces?
> 
> HasCallStack stack traces are one type of backtrace that the proposal
> supports. However, it's not the only (nor is it even the most useful
> sort, in my opinion).
> 
> Other mechanisms include cost center stacks from the cost-center
> profiler and native stack unwinding.
> 
>> 
>>> * Developers cannot easily produce stack traces do debug unintended 
>>> exceptions.
>> 
>> What are "unintended exceptions"?
>> What is an example of an "unintended exception"?
> 
> For instance,
> 
> * Somewhere deep in my code a colleague used `fromJust` due to a
>   miscommunicated invariant
> 
> * Somewhere in my system a `writeFile "tmp" $ repeat 'a'` failed due to
>   filling the disk
> 
> * Somewhere in my system I have a partial pattern match in a module
>   which was compiled without -Wall
> 
> * Somewhere in my system I `div` by zero due to lack of input
>   validation
> 
> * I use a record selector on a sum.
> 
> * A logic error results in an assertion failure deep in my program, but
>   it's unclear which path my program took to arrive at the assertion
> 
> This list could go on and on...
> 
> Currently the proposal does not cover asynchronous exceptions but it
> wouldn't be particularly hard to extend it in this direction. This would
> allow far better reporting of heap/stack overflows and MVar deadlocks
> (which are particularly hard to debug at the moment).
> 
> Cheers,
> 
> - Ben
> _______________________________________________
> ghc-devs mailing list
> [email protected]
> http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs

_______________________________________________
Haskell-Cafe mailing list
To (un)subscribe, modify options or view archives go to:
http://mail.haskell.org/cgi-bin/mailman/listinfo/haskell-cafe
Only members subscribed via the mailman list are allowed to post.