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

[Michael Truog]

On 12/04/2018 11:50 PM, Martin Bjorklund wrote:
> Hi,
>
> Michael Truog <mjtruog@REDACTED> wrote:
>> I know this is a bit after most comments have occurred, but it seems
>> ok since a decision hasn't been made yet.  I like the change to the
>> begin/end, even though it attaches some magic interpretation of an ok
>> 2-tuple and an error 2-tuple.
> I don't like it, for that particular reason.
>
>    Trying to make the begin/end change
>> more complex to handle other return values for Success/Error
>> conditions (perhaps by adding type specifications to the syntax)
>> doesn't seem like a good direction
> How about something like:
>
>    begin
>        {ok, A} =~ do_something(),
>        {true, B} =~ do_something_else(A),
>        ok =~ at_last(B)
>    end
>
> where =~ means that if the RHS value doesn't match the LHS expression,
> the RHS value is returned from the begin ... end expression.
>
> So if do_something_else() above returns false, the begin ... end would
> return false.
Yes, that approach is more generic and seems like a better fit into 
Erlang.  The operator choice may be better as ~= instead of =~ because 
the main existing asymmetric operator (focusing on the comparison 
operators) in Erlang is /= which matches the phrase "doesn't equal", 
with ~= matching "approximately equal".  Either way, it is a good way of 
avoiding the magic and the absence of the <- makes sense because nothing 
is really being unwrapped like a list element is in a list comprehension.
> But even with this, I'm not sure the benefits are worth the added
> complexity of the language.
The alternative is the approach with functions that have a list of 
anonymous functions.  The begin/end syntax addition helps to avoid the 
additional GC usage (less data required) and should be better for type 
specification, so the addition seems like it can be justified, from my 
point-of-view.

Best Regards,
Michael

>
>
> /martin