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

[Fred Hebert]

On Tue, Sep 11, 2018 at 11:58 AM, e@REDACTED <e@REDACTED> wrote:

>
> call it what you like.
> it is not cryptic, because it has clarity.
> and it ADDRESSES THE PROBLEM, not dancing around.
>
>
It provides non-linear flow to a greater extent than the current proposal,
and requires adding more syntax than the current proposal (both to create a
label, and to match on it later on). The problem here, as defined in
EEP-49, is using value-based error handling. There is little that dances
more around that than "using exceptions instead of values to do value-based
error handling".


> The problems with this form also include:
>>
>>   * you have to decide what happens if you specify a label that has no
>>     match in the catch section?
>>
>
> what happens to any value that is not caught?
>

It keeps going as a non-caught exception. However here you are specifically
specifying a label for which there is no match.


> but it seems better to limit the labels scope to the single try,
> and strip the labels from the return value of the try.
>

But you can't do that if you don't capture the exception, unless you
implicitly capture and re-raise all exceptions that had a label, or unless
you change how exceptions work in the language. This is a much, much bigger
change than what is being proposed in EEP-49.


>
>   * you have to decide what happens if you specify a pattern that eats
>>     up multiple labels in the catch section. Is this acceptable or it
>>     breaks the spirit of the feature?
>>
>
> why not?
>

in an EEP, you have to be able to explain why it makes sense, and why it
doesn't make sense. You could say it makes sense because that's how other
patterns work, for example. But if you simply say "why not?", then that's
not a very strong rationale, is it?


>
>   * can you guard on labels?
>>
>
> what?
>

Try ... catch expressions are allowed to guard on patterns. For example:

try
    Exp
catch
    error:{badmatch, X}:Stacktrace when X > 5 -> ...
end

Can guards be applied to labels, or can they not? For example, you can
currently pattern match on the exception class, the exception value, but
not the stacktrace itself. It is not obvious that you want or do not want
guards to apply to labels.


>
>   * can labels be dynamically generated or are they compile-time
>> constructs?
>>
>
> can try expressions be generated?
>

They can't without an evaluator, but you can generate values on which you
match:

X = f()
try
    Exp
catch
    error:{badmatch, X}:Stacktrace -> ...
end

will only match the badmatch exception if the value that failed was the
same as what f() returned. The exception class can also be made dynamic.
Should a label be made dynamic or purely static?


>
>   * the current syntax clashes with catching the result of throw({a,
>>     ErrorCode, ReturnValue}), which means the syntax is too ambiguous to
>>     serve its actual purpose without breaking backwards compatibility
>>
>
> the syntax is being DISCUSSED it is NOT CURRENT.
>

Fine: *The syntax you proposed and is being DISCUSSED clashes with catching
the result of throw({a, ErrorCode, ReturnValue}), which means the syntax is
too ambiguous to** serve its actual purpose without breaking backwards
compatibility*

So please, do some more work on your counter-proposal, since right now
you're essentially throwing the current EEP-49 proposal out wholesale in
favor of a fully different approach for which you have seemingly done
little to no research, and goes completely against the objectives of
having *value-based
error handling*. You're free to disagree with EEP-49 and say you hate it,
but I do not owe you a debate or a rubber-ducking session on how you should
flesh out your counter-proposal. I'd rather use my limited time to improve
the current one (biggest problem being _ <~ Exp being the only way to match
ok, but there appears to be no great way around that outside of explicit
patterns which also have problems), rather than figuring out how to make
yours work when you haven't made that effort yourself.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20180911/6ec11570/attachment.htm>