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

[Bryan Paxton]

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 <kenneth@REDACTED 
> <mailto: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
>
> 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
> eeps@REDACTED
> http://erlang.org/mailman/listinfo/eeps
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20201013/2d1abbaf/attachment-0001.htm>