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

Kenneth Lundin kenneth.lundin@REDACTED
Thu Nov 29 11:48:18 CET 2018 

On Tue, Nov 27, 2018 at 9:44 AM Raimo Niskanen <raimo+eeps@REDACTED>
wrote:

> On Mon, Nov 26, 2018 at 04:36:04PM -0500, Fred Hebert wrote:
> > Hi Raimo,
> >
> > any idea if this is due for some OTP committee discussion any time soon?
>
> I'll remind them...
> / Raimo
>

The OTP Technical Committee had a meeting where we discussed this EEP a
while ago and unfortunately the notes from this has been somewhat delayed.
But they will be published as soon as possible.
Maybe this thread can take a pause until they are published.

/Kenneth

>
>
> >
> > On Wed, Oct 3, 2018 at 3:10 AM Raimo Niskanen <raimo+eeps@REDACTED>
> wrote:
> >
> > > On Tue, Oct 02, 2018 at 10:27:02PM -0400, Fred Hebert wrote:
> > > > On 10/02, Raimo Niskanen wrote:
> > > > >I somehow feel a need to be able to distinguish between ok and
> {ok,_}.
> > > > >
> > > > >In your example for Reducing Nesting, Mnesia, the
> > > > >
> > > > >  _ <~ disk_log:sync(...)
> > > > >
> > > > >is not exactly equivalent to
> > > > >
> > > > >  case disk_log:sync(...) of
> > > > >      ok -> this;
> > > > >      {error,Reason} -> that
> > > > >  end
> > > > >
> > > > >since if disk_log:sync/1 would return {ok,_} that would be allowed
> after
> > > > >the rewrite to use <~ but case clause before.
> > > > >
> > > >
> > > > That is correct. In the case of `_ <~ Exp` the more equivalent match
> > > > expression would be:
> > > >
> > > >    case disk_log:sync(...) of
> > > >        ok -> this;
> > > >        {ok, _} -> this;
> > > >        {error,Reason} -> that
> > > >    end
> > > >
> > > > >I think being able to narrow possibilities in the code is a good
> thing,
> > > but
> > > > >I have not found a good way to squeeze it into this language
> extension.
> > > > >But I would like to be able to somehow specify to allow ok but not
> > > {ok,_}
> > > > >as a success value...
> > > >
> > > > Essentially, a flat `ok` is made similar to `{ok, <null>}` by the
> > > > pattern: it is really trying to say "unpack the good value",
> whatever it
> > > > is.
> > > >
> > > > You can allow `{ok, _}` but not `ok` by matching on `_Ignored <~ Exp`
> > > > since that binds a variable and 'ok' can't make that possible, but
> there
> > > > is indeed no way to say "I need this to be `ok` with no actual value
> > > > bound and also make sure nothing is returned aside from ok". This one
> > > > specific case would require you to use a case expression as you
> > > > currently would today.
> > > >
> > > > To make a distinction between these, I think would involve one of the
> > > > following:
> > > >
> > > > - ask for an explicit pattern (`{ok, _} <~ Exp` vs. `_ <~ Exp`, which
> > > >   means you can create invalid syntactic cases by using `{error, _}
> <~
> > > >   Exp`)
> > > > - allow the `<-` operator for exact matches (contains the caveats
> > > >   explained in earlier posts)
> > > > - introduce some prefix operator
> > > > - introduce a new kind of pattern to mean "No value returned", which
> is
> > > >   basically a terrible idea for a functional language IMO.
> > > >
> > > > I don't think any of these are nice enough either, at least compared
> to
> > > > the convenience of being able to handle `ok` as a positive return
> value
> > > > in general. Might as well use a case expression for these.
> > >
> > > Agreed.  Handling 'ok' as a positive return value is essential.
> > >
> > > >
> > > > The problem goes away entirely if `ok` is not possible to use with
> the
> > > > construct (you have to extract a value), but my guess is that this
> would
> > > > instead encourage people in the community to use `{ok, undefined}` as
> > > > return values to fit with nicer workflows.
> > >
> > > Agreed.
> > >
> > > >
> > > > A quick search yields 17 functions in all of OTP that currently use
> this
> > > > possible return value in a signature:
> > > >
> > > > $ ack -r '[^{]ok.*\|.*{ok,' | grep '\.erl' | wc -l
> > > > 17
> > > >
> > > > 2 of them are in test suites, at least 5 of them are using signatures
> > > > with over 3 variants of `ok | {ok, _} | {ok, _, _} | {ok, _, _, _}`
> > > > which wouldn't work anyway, and one of them is a false positive on
> the
> > > > regex.
> > > >
> > > > Of the 11 left, the most notable one is possibly ssl:close/2 (and
> ~3-4
> > > > variants) where the function can be used both to close the socket
> and to
> > > > downgrade it to a non-ssl connection. I would argue that the proper
> > > > thing would have been to have a 'downgrade' function, but this isn't
> > > > what's at stake here.
> > >
> > > Right.
> > >
> > > >
> > > > In any case, the pattern is likely rare in terms of possible
> producing
> > > > sites, but I couldn't say how it goes as far as call-sites are
> > > > concerned.
> > >
> > > 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'.
> > >
> > > 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
> > >
> > > >
> > > > >
> > > > >An interesting EEP.  A bit over-magical as Adam Lindberg thought -
> the
> > > > >relation to {ok,_} and {error,_} feels rather hidden in the <~
> operator.
> > > > >But I do not have a better suggestion. :-/
> > > > >
> > > >
> > > > Alright. Is this basically the EEP being turned down, or more of a
> > > > general remark, though?
> > >
> > > 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.
> > >
> > > --
> > >
> > > / Raimo Niskanen
> > > _______________________________________________
> > > eeps mailing list
> > > eeps@REDACTED
> > > http://erlang.org/mailman/listinfo/eeps
> > >
>
> --
>
> / Raimo Niskanen, Erlang/OTP, Ericsson AB
> _______________________________________________
> eeps mailing list
> eeps@REDACTED
> http://erlang.org/mailman/listinfo/eeps
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20181129/71d68dd1/attachment.htm>

More information about the eeps mailing list