[erlang-patches] Attempt at making stacktraces more readable

[unknown]

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

[unknown]

Post by unknown
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.

[unknown]

Post by unknown
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>

[unknown]

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

Post by unknown
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

[unknown]

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

Post by unknown
Ok. What about the eunit stacktraces?
--
Anthony Ramine

Post by unknown
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

[unknown]

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.

Post by unknown
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

Post by unknown
Ok. What about the eunit stacktraces?
--
Anthony Ramine

On Sun, May 5, 2013 at 3:45 PM, Anthony Ramine <n.oxyde>
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

[unknown]

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

Post by unknown
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
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.
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

Post by unknown
Ok. What about the eunit stacktraces?
--
Anthony Ramine

Post by unknown
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

[unknown]

Post by unknown
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]

On Mon, Dec 16, 2013 at 12:59 PM, Björn Gustavsson

Post by unknown

Post by unknown
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-Egil Dahlberg]

Post by Björn Gustavsson
On Mon, Dec 16, 2013 at 12:59 PM, Björn Gustavsson

Post by unknown

Post by unknown
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