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

[Fred Hebert]

On Wed, Sep 12, 2018 at 4:30 AM Loïc Hoguin <essen@REDACTED> wrote:

> On 09/10/2018 04:37 PM, Fred Hebert wrote:
> > If a single |begin ... end| block calls to these as the potential return
> > value of a function, the caller now has to have the following type
> > specification:
> >
> > |-spec caller() -> ok | {ok, term()} | {ok, term(), [warning()]} |
> > {error, term()} | {error, term(), term()}. |
>
> Isn't that incorrect? There's no reason the spec for caller() would have
> all 3 'ok' in its type since the resulting type would be either the
> error tuples OR the result of the last expression in the begin..end
> block (which may or may not be the left hand side of a <~ expression).
>
> So the spec for caller() would be:
>
> -spec caller() -> OK | {error, term()} | {error, term(), term()}.
>

You are right, yes,


> Somehow I do not see this as being a big problem, at least as far as
> specs go. There's very little code that's larger than a 3-tuple for
> error tuples, and even 3-tuples are not that common.
>
>
I did a quick check in the OTP repo.

For all error tuples:
$ ack -r '{error,' | wc -l
19725

I've grabbed a list of the files, split them into tokens with erl_parse,
and then counted the number of commas/tuples to account for nesting and
what I've found is something like this:

#{2 => 16848,3 => 2166,4 => 155,5 => 90,6 => 2}

Where each key is the number of terms in the tuple. Here's the same version
as percentages:

#{2 => 85.414,
  3 => 10.981,
  4 => 0.786,
  5 => 0.456,
  6 => 0.010}

It's not fully accurate, but it's probably representative of things, or in
the right order of magnitude.


> This would basically correspond to a case block where instead of
> matching on "{error, _}" and returning that, you would match on "Error
> when element(1, Error) =:= error".
>
> Doesn't sound like this would have negative performance implications
> either, it may actually be faster since you don't need to check the
> tuple size.
>
> This can be allowed regardless of the unwrapping done on ok tuples and
> whatever limitations they may have.
>
>
I don't have a strong opposition to this, especially if the unwrapping
remains in place. At this point I think this is a question where I'd like
to follow the OTP technical committee's preferences to get this feature
going. I see value in standardizing error tuples, but the gained
flexibility on error handling is not necessarily bad either (I'd really
like uniformity though!), at least not enough to make me think it would be
a mistake to do it. Whatever they prefer I'd be fine going with, I think.

It shouldn't lead to significant return value bloating at this point, and
I've made use of error triples in the past for some annotations. Though if
everyone headed towards 2-tuples for errors, I'd bet a nested tuple would
risk becoming a bit more common for annotations and structural data.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20180920/c522be45/attachment.htm>