Attempt at making stacktraces more readable

classic Classic list List threaded Threaded
10 messages Options
Reply | Threaded
Open this post in threaded view
|

Attempt at making stacktraces more readable

Anthony Ramine-2
Hello,

When an error isn't caught by a catch expression, the VM sends the faulty stacktrace as a string with a small message to the error logger. As it is already a string representation and not the stacktrace itself, the result may as well be readable and human-friendly. This is an attempt at making exactly this.

I have no idea how this will be received by the community, I'm just trying to spark a discussion about how we could improve the way stacktraces are currently printed.

To choose a format, Rosetta Code was my main source of inspiration [1].

        git fetch https://github.com/nox/otp.git better-error-reports

        https://github.com/nox/otp/compare/erlang:maint...better-error-reports
        https://github.com/nox/otp/compare/erlang:maint...better-error-reports.patch

Regards,

[1] http://rosettacode.org/wiki/Stack_traces

--
Anthony Ramine


Reply | Threaded
Open this post in threaded view
|

Attempt at making stacktraces more readable

Fredrik
On 05/05/2013 03:45 PM, Anthony Ramine wrote:

> Hello,
>
> When an error isn't caught by a catch expression, the VM sends the faulty stacktrace as a string with a small message to the error logger. As it is already a string representation and not the stacktrace itself, the result may as well be readable and human-friendly. This is an attempt at making exactly this.
>
> I have no idea how this will be received by the community, I'm just trying to spark a discussion about how we could improve the way stacktraces are currently printed.
>
> To choose a format, Rosetta Code was my main source of inspiration [1].
>
> git fetch https://github.com/nox/otp.git better-error-reports
>
> https://github.com/nox/otp/compare/erlang:maint...better-error-reports
> https://github.com/nox/otp/compare/erlang:maint...better-error-reports.patch
>
> Regards,
>
> [1] http://rosettacode.org/wiki/Stack_traces
>
Hello Anthony,
Your patch has been sent to be reviewed since it's significant changes
to the stacktrace. You will be updated of the outcome.

--

BR Fredrik Gustafsson
Erlang OTP Team


Reply | Threaded
Open this post in threaded view
|

Attempt at making stacktraces more readable

Björn Gustavsson-2
In reply to this post by Anthony Ramine-2
On Sun, May 5, 2013 at 3:45 PM, Anthony Ramine <n.oxyde> wrote:

>
> To choose a format, Rosetta Code was my main source of inspiration [1].
>
>
We think that it would be better if the stack traces would have the
same format as in the shell.

 /Bj?rn
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20130708/e0c5e3b7/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Attempt at making stacktraces more readable

Anthony Ramine-2
Ok. What about the eunit stacktraces?

--
Anthony Ramine

Le 8 juil. 2013 ? 12:02, Bj?rn Gustavsson a ?crit :

> On Sun, May 5, 2013 at 3:45 PM, Anthony Ramine <n.oxyde> wrote:
>
> To choose a format, Rosetta Code was my main source of inspiration [1].
>
>
> We think that it would be better if the stack traces would have the
> same format as in the shell.
>
>  /Bj?rn
>


Reply | Threaded
Open this post in threaded view
|

Attempt at making stacktraces more readable

Anthony Ramine-2
Ping?

I have trouble understanding what they should look like, as in a lot of situations the shell does not even print a stack trace.

Also the eunit format seems to be more verbose.

Regards,

--
Anthony Ramine

Le 8 juil. 2013 ? 12:11, Anthony Ramine <n.oxyde> a ?crit :

> Ok. What about the eunit stacktraces?
>
> --
> Anthony Ramine
>
> Le 8 juil. 2013 ? 12:02, Bj?rn Gustavsson a ?crit :
>
>> On Sun, May 5, 2013 at 3:45 PM, Anthony Ramine <n.oxyde> wrote:
>>
>> To choose a format, Rosetta Code was my main source of inspiration [1].
>>
>>
>> We think that it would be better if the stack traces would have the
>> same format as in the shell.
>>
>> /Bj?rn
>>
>


Reply | Threaded
Open this post in threaded view
|

Attempt at making stacktraces more readable

Björn Gustavsson-2
I did not understand your eunit question. Did you
ask whether you should update stacktraces
in eunit too?

I have not seen stacktrace in eunit, since I have
used eunit very little.

Here are some examples of stacktraces produced
by the shell:

1> lists:map(fun(X) -> X + 1 end, [a]).
** exception error: an error occurred when evaluating an arithmetic
expression
     in operator  +/2
        called as a + 1
     in call from lists:map/2 (lists.erl, line 1224)
2> lists:map(fun(X) -> lists:sum(X) + 1 end, [a]).
** exception error: no function clause matching lists:sum(a,0) (lists.erl,
line 276)
     in function  erl_eval:do_apply/6 (erl_eval.erl, line 573)
     in call from erl_eval:expr/5 (erl_eval.erl, line 395)
     in call from lists:map/2 (lists.erl, line 1224)
3>

The code that formats the stacktrace can be found
in lib.erl (in stdlib).

The point with my answer was that we didn't want significantly
different stacktraces depending on their origin. If you want
to rewrite how the shell formats stacktraces, that is also
fine. In that case, make sure that you include examples
of the stacktraces in the commit message so that we
can see how the stacktrace will look without having to
build the branch in order to see a stacktrace.




On Sat, Dec 14, 2013 at 12:46 PM, Anthony Ramine <n.oxyde> wrote:

> Ping?
>
> I have trouble understanding what they should look like, as in a lot of
> situations the shell does not even print a stack trace.
>
> Also the eunit format seems to be more verbose.
>
> Regards,
>
> --
> Anthony Ramine
>
> Le 8 juil. 2013 ? 12:11, Anthony Ramine <n.oxyde> a ?crit :
>
> > Ok. What about the eunit stacktraces?
> >
> > --
> > Anthony Ramine
> >
> > Le 8 juil. 2013 ? 12:02, Bj?rn Gustavsson a ?crit :
> >
> >> On Sun, May 5, 2013 at 3:45 PM, Anthony Ramine <n.oxyde>
> wrote:
> >>
> >> To choose a format, Rosetta Code was my main source of inspiration [1].
> >>
> >>
> >> We think that it would be better if the stack traces would have the
> >> same format as in the shell.
> >>
> >> /Bj?rn
> >>
> >
>
>


--
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20131216/fbd4ed01/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Attempt at making stacktraces more readable

Anthony Ramine-2
Thanks for the example.

Apart from the infix operators, I can print such stack traces easily. Would printing of operators as fully-qualified erlang function calls be a game breaker?

--
Anthony Ramine

Le 16 d?c. 2013 ? 12:42, Bj?rn Gustavsson <bgustavsson> a ?crit :

> I did not understand your eunit question. Did you
> ask whether you should update stacktraces
> in eunit too?
>
> I have not seen stacktrace in eunit, since I have
> used eunit very little.
>
> Here are some examples of stacktraces produced
> by the shell:
>
> 1> lists:map(fun(X) -> X + 1 end, [a]).
> ** exception error: an error occurred when evaluating an arithmetic expression
>      in operator  +/2
>         called as a + 1
>      in call from lists:map/2 (lists.erl, line 1224)
> 2> lists:map(fun(X) -> lists:sum(X) + 1 end, [a]).
> ** exception error: no function clause matching lists:sum(a,0) (lists.erl, line 276)
>      in function  erl_eval:do_apply/6 (erl_eval.erl, line 573)
>      in call from erl_eval:expr/5 (erl_eval.erl, line 395)
>      in call from lists:map/2 (lists.erl, line 1224)
> 3>
>
> The code that formats the stacktrace can be found
> in lib.erl (in stdlib).
>
> The point with my answer was that we didn't want significantly
> different stacktraces depending on their origin. If you want
> to rewrite how the shell formats stacktraces, that is also
> fine. In that case, make sure that you include examples
> of the stacktraces in the commit message so that we
> can see how the stacktrace will look without having to
> build the branch in order to see a stacktrace.
>
>
>
>
> On Sat, Dec 14, 2013 at 12:46 PM, Anthony Ramine <n.oxyde> wrote:
> Ping?
>
> I have trouble understanding what they should look like, as in a lot of situations the shell does not even print a stack trace.
>
> Also the eunit format seems to be more verbose.
>
> Regards,
>
> --
> Anthony Ramine
>
> Le 8 juil. 2013 ? 12:11, Anthony Ramine <n.oxyde> a ?crit :
>
> > Ok. What about the eunit stacktraces?
> >
> > --
> > Anthony Ramine
> >
> > Le 8 juil. 2013 ? 12:02, Bj?rn Gustavsson a ?crit :
> >
> >> On Sun, May 5, 2013 at 3:45 PM, Anthony Ramine <n.oxyde> wrote:
> >>
> >> To choose a format, Rosetta Code was my main source of inspiration [1].
> >>
> >>
> >> We think that it would be better if the stack traces would have the
> >> same format as in the shell.
> >>
> >> /Bj?rn
> >>
> >
>
>
>
>
> --
> Bj?rn Gustavsson, Erlang/OTP, Ericsson AB


Reply | Threaded
Open this post in threaded view
|

Attempt at making stacktraces more readable

Björn Gustavsson-2
On Mon, Dec 16, 2013 at 12:46 PM, Anthony Ramine <n.oxyde> wrote:

> Thanks for the example.
>
> Apart from the infix operators, I can print such stack traces easily.
> Would printing of operators as fully-qualified erlang function calls be a
> game breaker?
>
>
No, it wouldn't. Minor differences are OK if
it simplifies the code in the run-time system.

--
Bj?rn Gustavsson, Erlang/OTP, Ericsson AB
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-patches/attachments/20131216/b8fec3a4/attachment.html>

Reply | Threaded
Open this post in threaded view
|

Re: Attempt at making stacktraces more readable

Björn Gustavsson
On Mon, Dec 16, 2013 at 12:59 PM, Björn Gustavsson
<[hidden email]> wrote:

> On Mon, Dec 16, 2013 at 12:46 PM, Anthony Ramine <[hidden email]> wrote:
>>
>> Thanks for the example.
>>
>> Apart from the infix operators, I can print such stack traces easily.
>> Would printing of operators as fully-qualified erlang function calls be a
>> game breaker?
>>
>
> No, it wouldn't. Minor differences are OK if
> it simplifies the code in the run-time system.
>

If you want to do further work on this topic,
create a pull request.

--
Björn Gustavsson, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-patches mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-patches
Reply | Threaded
Open this post in threaded view
|

Re: Attempt at making stacktraces more readable

Björn-Egil Dahlberg-5
On 2015-02-25 11:37, Björn Gustavsson wrote:

> On Mon, Dec 16, 2013 at 12:59 PM, Björn Gustavsson
> <[hidden email]> wrote:
>> On Mon, Dec 16, 2013 at 12:46 PM, Anthony Ramine <[hidden email]> wrote:
>>> Thanks for the example.
>>>
>>> Apart from the infix operators, I can print such stack traces easily.
>>> Would printing of operators as fully-qualified erlang function calls be a
>>> game breaker?
>>>
>> No, it wouldn't. Minor differences are OK if
>> it simplifies the code in the run-time system.
>>
> If you want to do further work on this topic,
> create a pull request.
>

Anthony, beware .. as you probably already know this in the same area as
https://github.com/erlang/otp/pull/359

If we can mitigate the memory issue, I think sending a term and then
formatting it in Erlang would be better. Less code in beam is always
better in my view.
I haven't looked at the whole error-handling stack recently though, I
could be missing something.

// Björn-Egil


_______________________________________________
erlang-patches mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-patches