Re: [Haskell-cafe] Decorating exceptions with backtrace information

On Fri, 8 May 2020, Ben Gamari wrote:

> Henning Thielemann <[email protected]> writes:
>
>> 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.


Interesting. That's a completely new thing.


>>> * 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

That's a programming error.

> * Somewhere in my system a `writeFile "tmp" $ repeat 'a'` failed due to
>   filling the disk

Hm, that's also a programming error, but it ends in an IO exception. If it 
would not end in an IO exception (e.g. writing to /dev/null) it would go 
to an infinite loop. Anyway, it is a programming error. However it is an 
unchecked one. That is, there is no warranty that you can catch it by a 
debugger. So I do not think you can achieve much with callstacks here.

> * Somewhere in my system I have a partial pattern match in a module
>   which was compiled without -Wall

Programming error and btw. before thinking about a GHC extension I would 
enable -Wall ...

> * Somewhere in my system I `div` by zero due to lack of input
>   validation

Programming error

> * I use a record selector on a sum.

Programming error

> * 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

Sounds like Programming error


> This list could go on and on...

From your list of examples I deduce that the proposal is about programming 
errors. But we have HasCallStack for that one. How does the proposal 
improve or alter the HasCallStack solution? And how does it relate to the 
IO exception system with hierarchical exceptions and SomeException and so 
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).

Hm, what kind of heap or stack overflow are you thinking of?

A stack overflow sounds like unlimited recursion and thus like a 
programming error. In contrast to that, a program must be prepared for a 
failure of "malloc". Memory exhaustion is an IO exception, it should be 
explicit in the type.

Are MVar deadlocks always detected by the runtime system?
_______________________________________________
Glasgow-haskell-users mailing list
[email protected]
http://mail.haskell.org/cgi-bin/mailman/listinfo/glasgow-haskell-users