On Fri, 8 May 2020, Ben Gamari wrote:
Henning Thielemann <lemm...@henning-thielemann.de> 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?
_______________________________________________
ghc-devs mailing list
ghc-devs@haskell.org
http://mail.haskell.org/cgi-bin/mailman/listinfo/ghc-devs