100% +1 +1 +1
--
Bryan
On 10/13/20 8:42 AM, Fred Hebert wrote:
On Fri, Dec 7, 2018 at 6:28 AM Kenneth Lundin <[email protected]
<mailto:[email protected]>> wrote:
EEP-0049 Value-based Error handling mechanisms
* We don't like a language construct which is hard coded to
support ok,{ok,Result}, {error,Reason}.
* the use of underscore _ <~ to mean a match with ok is not a
hit, it will make programs harder to read
* We are against the introduction of /unwrapexprs/ that cannot
be used everywhere where expressions are allowed.
* The /unwrapexpr/ changes the scoping rules and can not be used
in nested expressions and not outside begin ... end.
It is perfectly possible to use throw and try catch to replace or
simplify deeply-nested case ... end expressions in the same way as
the proposed language extension does.
...
Summary
* We say no to the proposed language extensions. We don't think
they are general enough and we also see some problems with them.
* The same effect can be achieved safely with the current
language using throw, try...catch.
* Encouraging |ok, {ok,Result}, {error,Reason}| as results from
functions can be done in other ways, for example through
library functions. These values should not be special to the
/language/.
* We also want to thank the author for a very well thought
through and well documented proposal which has triggered us to
think about possible solutions in this area. We really
appreciate the effort.
/Kenneth, Erlang/OTP Ericsson
I'd like to come back and revisit this.
I won't re-expand on my disdain for try...catch based control-flow for
common cases, but I was wondering what would the opinion of the OTP
team be if I were to re-work the proposal towards a less /opinionated/
approach to this control flow, something possibly more in line with
Elixir's with.
Currently the simplest way to transform this proposal is probably to
allow the pattern on the left-hand-side of <~ to be any pattern, and
only escape the begin...end construct as a short-circuit return:
begin
{ok, X} = exp(), % hard crash if it doesn't match
{ok, X} <~ exp(), % if it fails, begin...end returns the value of
the non-matching term
...
end
This gets rid of the _ <~ rhs() magic syntax, drops prescriptiveness
of ok | {ok, T} | {error, R} returns, but maintains high-level control
flow that doesn't risk transforming non-local returns into values
(which forces rewriting unrelated code to work nicely with high-level
conditional flows and clashes with value-based error handling) and
establishing a sort of conditional pipeline. It does lose some of the
safety mentioned in the original proposal, but we can't maintain that
safety without normalizing acceptable good or error values, which the
OTP team has mentioned not wanting to do at the language level.
Of course the logical expansion of it is going for:
case
begin
{ok, X} = exp(), % hard crash if it doesn't match
{ok, Y} <~ exp(), % if it fails, begin...end returns the value of
the non-matching term
...
end
of
{ok, Good} -> ...;
{error, Reason} -> ...;
end
which brings in whether a proposal rework that goes for something
closer to Elixir's with
<https://www.openmymind.net/Elixirs-With-Statement/> would be interesting.
Let me know if there's interest and I can rework things. I keep
feeling the pain of complex validation flows time and time again
there, particularly whenever there is one single good path and many
bad paths possible for each validation step.
_______________________________________________
eeps mailing list
[email protected]
http://erlang.org/mailman/listinfo/eeps
_______________________________________________
eeps mailing list
[email protected]
http://erlang.org/mailman/listinfo/eeps
