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

[Raimo Niskanen]

On Tue, Sep 04, 2018 at 05:07:03PM -0400, Fred Hebert wrote:
> This EEP adds a contextual <~ operator to begin ... end expressions, 
> which allows them to be usable for value-based error handling, based on 
> standard {ok, term()} | {error, term()} return value types.
> 
> This lets begin ... end become a control flow construct to replace or 
> simplify deeply-nested case ... end expressions, and prevent using 
> exceptions for control flow.
> 
> I want to thank Jesper Louis Andersen, Sean Cribbs, Tristan Sloughter, 
> Evan Vigil-McClanahan, Anthony Ramine, Bryan Paxton, and Pedram Nimreezi 
> for their feedback on this document.
> 
> The draft is attached to this document, and also available (along with 
> an incomplete reference implementation to explore some semantics) at 
> https://bitbucket.org/ferd/unwrap
> 
> Sorry for sending a first copy without the attachment,
> Fred.

I somehow feel a need to be able to distinguish between ok and {ok,_}.

In your example for Reducing Nesting, Mnesia, the

  _ <~ disk_log:sync(...)

is not exactly equivalent to

  case disk_log:sync(...) of
      ok -> this;
      {error,Reason} -> that
  end

since if disk_log:sync/1 would return {ok,_} that would be allowed after
the rewrite to use <~ but case clause before.

I think being able to narrow possibilities in the code is a good thing, but
I have not found a good way to squeeze it into this language extension.
But I would like to be able to somehow specify to allow ok but not {ok,_}
as a success value...

An interesting EEP.  A bit over-magical as Adam Lindberg thought - the
relation to {ok,_} and {error,_} feels rather hidden in the <~ operator.
But I do not have a better suggestion. :-/

Best Regards
-- 

/ Raimo Niskanen, Erlang/OTP, Ericsson AB