[eeps] EEP 049: Value-Based Error Handling Mechanisms

[Kenneth Lundin]

 We welcome initiatives like this and are positive to revisit this.
A proposal for something closer to *with* in Elixir looks interesting.

See more initial comments below:

On Tue, Oct 13, 2020 at 3:42 PM Fred Hebert <mononcqc@REDACTED> wrote:

>
> On Fri, Dec 7, 2018 at 6:28 AM Kenneth Lundin <kenneth@REDACTED> 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
>
The above feels like the right direction where {ok,Result} and {error,
Reason} has no hard coded interpretation in the language.

>
>
> 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.
>
> Yes, there is interest and I think it would be good to exchange ideas even
before there is a complete reworked EEP.

/Kenneth, Erlang/OTP Ericsson
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20201015/7bc67a36/attachment.htm>