[erlang-questions] EEP 47: Syntax in try/catch to retrieve the stacktrace directly

[Richard Carlsson]

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 <attila.r.nohl@REDACTED>:

> 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
> <jesper.louis.andersen@REDACTED>:
> > 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 <bjorn@REDACTED>
> 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
> >> erlang-questions@REDACTED
> >> http://erlang.org/mailman/listinfo/erlang-questions
> >
> >
> > _______________________________________________
> > erlang-questions mailing list
> > erlang-questions@REDACTED
> > http://erlang.org/mailman/listinfo/erlang-questions
> >
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://erlang.org/mailman/listinfo/erlang-questions
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/erlang-questions/attachments/20171127/08c461a2/attachment.htm>