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

[Fred Hebert]

 Sorry for my last e-mail just going for "are you asking for GOTO". Let me
dig into it on a more technical level instead. This isn't exactly a GOTO,
but rather similar to labelled breaks, which are a specialization of the
jump mechanism used in a GOTO.

In any case, your suggestion isn't exactly workable with the current syntax
if only because it clashes with existing forms:

a: <Exp>

is essentially a new operator, ':' which binds exceptions of '<Exp>' to the
label 'a'. If you change the operator for something you dislike, such as
<~, you get:

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.

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? Is it bubbled up to the next try ... catch in
   the stack or is it blowing up to a new exception type?
   - 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?
   - can you guard on labels?
   - can labels be dynamically generated or are they compile-time
   constructs?
   - 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 : operator is already used for fully qualified function calls, so
   what if you try to label a function call? You may now get label:function()
   which is ambiguous. You may be forced to actually use an operator that
   isn't a colon to make your form work.

And even with all of that, it still does not do a very good job at
value-based error handling. There are more pitfalls in this proposal than
the current one, and I don't know that you can make something work well in
there without introducing more syntax than the current proposal actually
would.

I would add that while I'm fine trying to explore these patterns, I will
not take the time to explore all of their nooks and crannies in full depth.
This one proposal is a quick thing you've thrown my way, but it has enough
pitfalls that it would take too much time to actually study it properly.
It's a lot of work, and I would encourage you to possibly write your own
EEP if you truly believe it should supercede EEP-49.

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

> On 09/11/18 17:19, Fred Hebert wrote:
>
>> are you arguing in favor of GOTO instead of an operator?
>>
>
> i hope it was a temporary brownout of your mind.
>
>
>
>
>> On Tue, Sep 11, 2018 at 11:09 AM, e@REDACTED <mailto:e@REDACTED> <
>> e@REDACTED <mailto:e@REDACTED>> wrote:
>>
>>              i'm sorry to interrupt,
>>              but all you REALLY NEED is to tweak the "try..catch" a
>>         little bit,
>>              in a manner that the catch clause receives and returns
>>              more comprehensible values, the values that are clearly
>> linked
>>              with the failed expressions and human readable.
>>
>>              you do not need a new messy CRYPTIC operator.
>>
>>              try
>>                 {ok, Result} = foo(...)
>>              , {ok, _} = foo2(...)
>>              catch
>>                {somehow_identify_which_line_failed,
>>         unobscured_the_rightside_value}
>>
>>
>>         This here is exactly the problem -- you can't somehow identify
>>         which line failed unobscured with the right value.
>>
>>
>>     [irrelevant technicalities skipped]
>>
>>     so this problem should be solved.
>>     exactly this problem.
>>     and another operator is not a solution.
>>
>>     option 1:
>>     you introduce labels in the try's context
>>
>>     try
>>        a: {ok, Result} = foo()
>>     , b: {ok, R} = foo2()
>>     catch
>>        {a, Error_Code, Actual_Return_Value} -> ...
>>     ; {b, _} -> ...
>>     end
>>
>>
>>
>

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

> On 09/11/18 17:19, Fred Hebert wrote:
>
>> are you arguing in favor of GOTO instead of an operator?
>>
>
> i hope it was a temporary brownout of your mind.
>
>
>
>
>> On Tue, Sep 11, 2018 at 11:09 AM, e@REDACTED <mailto:e@REDACTED> <
>> e@REDACTED <mailto:e@REDACTED>> wrote:
>>
>>              i'm sorry to interrupt,
>>              but all you REALLY NEED is to tweak the "try..catch" a
>>         little bit,
>>              in a manner that the catch clause receives and returns
>>              more comprehensible values, the values that are clearly
>> linked
>>              with the failed expressions and human readable.
>>
>>              you do not need a new messy CRYPTIC operator.
>>
>>              try
>>                 {ok, Result} = foo(...)
>>              , {ok, _} = foo2(...)
>>              catch
>>                {somehow_identify_which_line_failed,
>>         unobscured_the_rightside_value}
>>
>>
>>         This here is exactly the problem -- you can't somehow identify
>>         which line failed unobscured with the right value.
>>
>>
>>     [irrelevant technicalities skipped]
>>
>>     so this problem should be solved.
>>     exactly this problem.
>>     and another operator is not a solution.
>>
>>     option 1:
>>     you introduce labels in the try's context
>>
>>     try
>>        a: {ok, Result} = foo()
>>     , b: {ok, R} = foo2()
>>     catch
>>        {a, Error_Code, Actual_Return_Value} -> ...
>>     ; {b, _} -> ...
>>     end
>>
>>
>>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20180911/cf549e94/attachment.htm>