EEP 47: Syntax in try/catch to retrieve the stacktrace directly

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
8 messages Options
Reply | Threaded
Open this post in threaded view
|

EEP 47: Syntax in try/catch to retrieve the stacktrace directly

Björn Gustavsson-4
There is a new EEP that proposes a new syntax in try/catch to retrieve
the stacktrace directly without using erlang:get_stacktrace/0:

https://github.com/erlang/eep/blob/master/eeps/eep-0047.md

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

Re: EEP 47: Syntax in try/catch to retrieve the stacktrace directly

Jesper Louis Andersen-2
I think this is a sensible change all in all, and one which should be done.

My major gripe with it is the fact that you cannot pattern match on the stack trace. I see why this is done, but it feels like being a special arbitrary rule which goes against other matching patterns in the language. I'm not sure how it would help

catch
   Cl:Err:Stk ->
        case {Cl, Err, Stk} of
          ...
end

What I really like about the change is that it removes get_stacktrace/0 which is a "bad function", and one of those things I tend to call a "language mistake" in Erlang[0].

[0] For the interested, I think one of the most obvious mistakes are that a floating point numbers in Erlang cannot express NaNs and Infinities.

On Fri, Nov 24, 2017 at 10:05 AM Björn Gustavsson <[hidden email]> wrote:
There is a new EEP that proposes a new syntax in try/catch to retrieve
the stacktrace directly without using erlang:get_stacktrace/0:

https://github.com/erlang/eep/blob/master/eeps/eep-0047.md

/Björn
--
Björn Gustavsson, Erlang/OTP, Ericsson AB
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: EEP 47: Syntax in try/catch to retrieve the stacktrace directly

Attila Rajmund Nohl
Once I worked with a library that implemented the "let it crash"
philosophy to the maximum - for valid input I got the result, for
invalid input I got function_clause, badarg, badmatch, etc. crashes. I
tried to be clever and match on the output of erlang:get_stacktrace()
to decide if the error came from this particular library or from a
different code (in order to provide more meaningful error message to
the user), but eventually it didn't work out. In that case matching on
the stack trace might have been useful, but as it didn't work out in
the end, I don't think it's such a big deal that I can't match on the
stacktrace.

2017-11-25 15:17 GMT+01:00 Jesper Louis Andersen
<[hidden email]>:

> I think this is a sensible change all in all, and one which should be done.
>
> My major gripe with it is the fact that you cannot pattern match on the
> stack trace. I see why this is done, but it feels like being a special
> arbitrary rule which goes against other matching patterns in the language.
> I'm not sure how it would help
>
> catch
>    Cl:Err:Stk ->
>         case {Cl, Err, Stk} of
>           ...
> end
>
> What I really like about the change is that it removes get_stacktrace/0
> which is a "bad function", and one of those things I tend to call a
> "language mistake" in Erlang[0].
>
> [0] For the interested, I think one of the most obvious mistakes are that a
> floating point numbers in Erlang cannot express NaNs and Infinities.
>
> On Fri, Nov 24, 2017 at 10:05 AM Björn Gustavsson <[hidden email]> wrote:
>>
>> There is a new EEP that proposes a new syntax in try/catch to retrieve
>> the stacktrace directly without using erlang:get_stacktrace/0:
>>
>> https://github.com/erlang/eep/blob/master/eeps/eep-0047.md
>>
>> /Björn
>> --
>> Björn Gustavsson, Erlang/OTP, Ericsson AB
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: EEP 47: Syntax in try/catch to retrieve the stacktrace directly

Richard Carlsson-3
I agree that this is a good change. I can't even recall exactly why we went with the get_stacktrace() BIF - particularly since the value is already present as a variable under the hood. But I guess it was precisely to avoid such discussions about pattern matching on stack traces or having arbitrary restrictions such as "may only be a variable" on a part of a pattern. But I think such a restriction makes sense.

The main problem with code that matches on the format of the stack trace is that it creates a hard dependency on the current format of the stack trace - which has changed more than once and might change again. The general rule is Don't Do That, and if you still feel that you have to, at least limit it to a single support function, not spread all over your code.

        /Richard

2017-11-26 14:40 GMT+01:00 Attila Rajmund Nohl <[hidden email]>:
Once I worked with a library that implemented the "let it crash"
philosophy to the maximum - for valid input I got the result, for
invalid input I got function_clause, badarg, badmatch, etc. crashes. I
tried to be clever and match on the output of erlang:get_stacktrace()
to decide if the error came from this particular library or from a
different code (in order to provide more meaningful error message to
the user), but eventually it didn't work out. In that case matching on
the stack trace might have been useful, but as it didn't work out in
the end, I don't think it's such a big deal that I can't match on the
stacktrace.

2017-11-25 15:17 GMT+01:00 Jesper Louis Andersen
<[hidden email]>:
> I think this is a sensible change all in all, and one which should be done.
>
> My major gripe with it is the fact that you cannot pattern match on the
> stack trace. I see why this is done, but it feels like being a special
> arbitrary rule which goes against other matching patterns in the language.
> I'm not sure how it would help
>
> catch
>    Cl:Err:Stk ->
>         case {Cl, Err, Stk} of
>           ...
> end
>
> What I really like about the change is that it removes get_stacktrace/0
> which is a "bad function", and one of those things I tend to call a
> "language mistake" in Erlang[0].
>
> [0] For the interested, I think one of the most obvious mistakes are that a
> floating point numbers in Erlang cannot express NaNs and Infinities.
>
> On Fri, Nov 24, 2017 at 10:05 AM Björn Gustavsson <[hidden email]> wrote:
>>
>> There is a new EEP that proposes a new syntax in try/catch to retrieve
>> the stacktrace directly without using erlang:get_stacktrace/0:
>>
>> https://github.com/erlang/eep/blob/master/eeps/eep-0047.md
>>
>> /Björn
>> --
>> Björn Gustavsson, Erlang/OTP, Ericsson AB
>> _______________________________________________
>> erlang-questions mailing list
>> [hidden email]
>> http://erlang.org/mailman/listinfo/erlang-questions
>
>
> _______________________________________________
> erlang-questions mailing list
> [hidden email]
> http://erlang.org/mailman/listinfo/erlang-questions
>
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions


_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: EEP 47: Syntax in try/catch to retrieve the stacktrace directly

Björn Gustavsson-4
In reply to this post by Jesper Louis Andersen-2
On Sat, Nov 25, 2017 at 3:17 PM, Jesper Louis Andersen
<[hidden email]> wrote:
[...]
>
> My major gripe with it is the fact that you cannot pattern match on the
> stack trace.

Yes, I don't like that inconsistency myself, but I
think that the alternatives are worse.

If we were to implement pattern matching on the
stacktrace, it would be much slower than the
matching the pattern for the exception. I find
that kind of performance trap to be worse
than not allowing matching in the first place.

I have updated the pull request so that there
is now a compilation error if the variable for
the stacktrace is already bound. The compiler
already gives an error if an attempt is made
to use the stacktrace variable in the guard.

Since the compiler is that strict, it would be
a compatible change to implement matching
in the future, if it turns out that is desirable
or reduces user confusion.

/Björn

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

Re: EEP 47: Syntax in try/catch to retrieve the stacktrace directly

Björn Gustavsson-4
In reply to this post by Richard Carlsson-3
On Mon, Nov 27, 2017 at 9:41 AM, Richard Carlsson
<[hidden email]> wrote:
> I agree that this is a good change. I can't even recall exactly why we went
> with the get_stacktrace() BIF - particularly since the value is already
> present as a variable under the hood. But I guess it was precisely to avoid
> such discussions about pattern matching on stack traces or having arbitrary
> restrictions such as "may only be a variable" on a part of a pattern. But I
> think such a restriction makes sense.

I have a vague memory that it was also problems with the parser. I had
to to refactor the yecc rules a bit to get it to work.

/Björn

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

Re: EEP 47: Syntax in try/catch to retrieve the stacktrace directly

Jesper Louis Andersen-2
In reply to this post by Björn Gustavsson-4
On Mon, Nov 27, 2017 at 3:22 PM Björn Gustavsson <[hidden email]> wrote:
On Sat, Nov 25, 2017 at 3:17 PM, Jesper Louis Andersen
<[hidden email]> wrote:
[...]
>
> My major gripe with it is the fact that you cannot pattern match on the
> stack trace.

Yes, I don't like that inconsistency myself, but I
think that the alternatives are worse.

 
Yes, I think so too. In a typed language, you would probably declare an abstract type for the stack and not provide any kind of matching pattern for it. This would force people to handle the stack by printing, and there would be no matching on it at all.

Mimicking this behavior in Erlang is probably the sane behavior in this case.

I also like Richard's point: matching on the stack will eventually get you into trouble.

_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions
Reply | Threaded
Open this post in threaded view
|

Re: EEP 47: Syntax in try/catch to retrieve the stacktrace directly

Attila Rajmund Nohl
2017-11-27 15:31 GMT+01:00 Jesper Louis Andersen
<[hidden email]>:

> On Mon, Nov 27, 2017 at 3:22 PM Björn Gustavsson <[hidden email]> wrote:
>>
>> On Sat, Nov 25, 2017 at 3:17 PM, Jesper Louis Andersen
>> <[hidden email]> wrote:
>> [...]
>> >
>> > My major gripe with it is the fact that you cannot pattern match on the
>> > stack trace.
>>
>> Yes, I don't like that inconsistency myself, but I
>> think that the alternatives are worse.
>>
>
> Yes, I think so too. In a typed language, you would probably declare an
> abstract type for the stack and not provide any kind of matching pattern for
> it. This would force people to handle the stack by printing, and there would
> be no matching on it at all.
>
> Mimicking this behavior in Erlang is probably the sane behavior in this
> case.

If the stack trace is strictly for human consumption, why not return a
string (list or binary)?
_______________________________________________
erlang-questions mailing list
[hidden email]
http://erlang.org/mailman/listinfo/erlang-questions