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

[Fred Hebert]

On 10/03, Raimo Niskanen wrote:
>
>The use I have in mind for matching 'ok' explicitly is simply that when you
>write your code you know that the return value should be 'ok', and you want
>to guard yourself from future mistakes where you e.g change the called
>function to a not as equivalent as you thought.
>
>Also for the code reader it is nice to know that there is no value
>discarded here, and for the final value that you do not have to look up
>the called function to know that the function you just wrote will only
>return 'ok'.
>

Yes, that's a fair requirement.

>So I am just for basic narrowing of possibilities...
>
>I guess an empty pattern is not possible?
>
>    begin
>	Whom <~ id({ok,"world"}),
>	<~ io:format("Hello, ~p!\n", [Whom])
>    end
>

It would be possible. There's a unary '+' and '-' prefix operator, and I 
figure it should be possible to declare '<~' both as infix and prefix.  

begin
    A + B,
    + 5,
    A <~ B,
    <~ B,
end

It does look a bit odd, but I do not think there is any case where it 
would be syntactically or grammatically ambiguous to use.

I think we'd be trading one kind of magic feeling (`_` can be used for 
both `{ok, _}` and `ok`) for another one (a unary unbind operator), but 
there would certainly be a clearer semantic distinction between `ok` and 
`{ok, _}`.

I just hadn't considered keeping the same operator both as infix and 
unary, but I'm certainly open to the idea.

What would be left to decide is whether introducing the operator would 
replace the currently proposed '_ <~ Exp' matching on 'ok' semantics or 
supplement it. I think it would make sense to replace it for that case 
wholesale.

>Nono, that, and all the above, are just my personal opinions.  Not the 
>OTP
>opinion.  And that remark was a general one along Adam Lindberg's line
>that I also like the explicitness in Erlang, and this EEP hides the {ok,_}
>and {error,_} patterns, which sacrifices explicitness for convenience.
>
>I think the convenience of the programming pattern that becomes possible
>is really useful, though.
>
>>
>> I'm curious what the next steps are. If the overall feeling is "nice but
>> not nice enough", I'd rather see the EEP rejected than left to linger
>> for many years, as seems to be the case with multiple EEPs in the past,
>> so at least I know where to stand.
>
>I accidentally jumped out of line when answering here...
>
>A few internal meetings are coming up before there can be any OTP opinions.
>

Understood !