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

e@REDACTED e@REDACTED
Tue Sep 11 17:58:16 CEST 2018


> try
>   a <~ {ok, Result} = foo()
> , b <~ {ok, R} = foo2()
> catch
>   {a, Error_Code, Actual_Return_Value} -> ...
> ; {b, _} -> ...
> end
> 
> Which essentially allows the same exact syntactic form you initially 
> disliked (a CRYPTIC operator), just with a different choice of what the 
> actual operator should be.

call it what you like.
it is not cryptic, because it has clarity.
and it ADDRESSES THE PROBLEM, not dancing around.


> 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?
but it seems better to limit the labels scope to the single try,
and strip the labels from the return value of the try.

>   * 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?

>   * can you guard on labels?

what?

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

can try expressions be generated?

>   * 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.

>   * the : operator is already used for fully qualified function calls,

same

DIXI.



More information about the eeps mailing list