On Tue, 12 May 2020 at 17:30, Henning Thielemann <
lemm...@henning-thielemann.de> wrote:
> 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
Am 12.05.20 um 23:29 schrieb Henning Thielemann:
> A stack overflow sounds like unlimited recursion and thus like a
> programming error.
Perhaps it was just one recursion to many? Computer memory is limited.
Heap overflow is also quite possible even with a program that is
provably terminating. I
On 5/12/20 10:55 PM, Henning Thielemann wrote:
> "This operation may fail with:
>
> * ResourceVanished if the handle is a pipe or socket, and the reading end is
> closed."
>
> That is, ResourceVanished is part of the public interface and in no way
> unexpected (or what "unintended" may be). I
On Fri, 8 May 2020, Ben Gamari wrote:
Henning Thielemann 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,
On Fri, 8 May 2020, Ben Gamari wrote:
We can debate whether partial functions like `fromJust` should exist; however,
the fact of the matter is that they do exist and they are used.
That's not my point. I say: fromJust on Nothing is a programming error,
ok. We must debug this. HasCallStack
On Fri, 8 May 2020, Niklas Hambüchen wrote:
What are "unintended exceptions"?
What is an example of an "unintended exception"?
A recent example from my production server:
hPutBuf: resource vanished (Broken pipe)
Ok, I lookup the Haddock comment of hPutBuf and it says:
"This operation
Ben,
I agree with you that is a great idea!
I can add a few more real world examples:
* we get exception from a foreign library that we bound,
* we get an exception from a platform (I believe Windows supports
throwing exceptions to programs),
* user presses CTRL-C and we want to know where our
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 999 beers. Orders a lizard. Orders -1 beers.
> First real customer walks in and asks where the bathroom is. The bar bursts
> into flames, killing
Henning Thielemann 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
Henning Thielemann writes:
> On Fri, 8 May 2020, Niklas Hambüchen wrote:
>
>> On 5/8/20 5:37 PM, Henning Thielemann wrote:
>>
>>> a callstack is not useful for a user.
>>
>> Call stacks have been very useful to me as a user of non-Haskell tools
>> so far, because they are excellent for
On 5/8/20 7:52 PM, Henning Thielemann wrote:
> We are talking about the HasCallStack stack traces, yes?
> How is their emission addressed by extending exceptions with stack traces?
The way I understand the proposal, we may be equally talking about DWARF or
profiling cost-center based stack
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
On 5/8/20 7:32 PM, Henning Thielemann wrote:
> This confirms that they are not for you, but you only forward them to the
> developer.
Yes, stack traces are in general for developers.
> Can someone please give me examples where current state lacks
* Currently stack traces are not printed, so
On Fri, 8 May 2020, Niklas Hambüchen wrote:
On 5/8/20 5:37 PM, Henning Thielemann wrote:
a callstack is not useful for a user.
Call stacks have been very useful to me as a user of non-Haskell tools
so far, because they are excellent for attaching to bug reports and
usually led to
On 5/8/20 5:37 PM, Henning Thielemann wrote:
> I can imagine that it would be helpful for the user to get a stacked
> exception information like:
> Parse error on line 42, column 23
> while reading file "foo/bar"
> while traversing directory "blabla"
That seems to be rather specific use
There seem to be multiple beginnings of the discussion. What is currently
discussed?
If someone says "exceptions" and "backtrace" in one sentence, I suspect
like many times before, that again confusion of the concepts of exceptions
and errors is ahead. Errors already support call stacks.
16 matches
Mail list logo
