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

[Fred Hebert]

On Mon, Sep 17, 2018 at 4:41 AM Robert Virding <rvirding@REDACTED> wrote:

> Sorry I have missed this until now. Isn't this similar to the elixir 'with
> ... do ... error ... end' construct? At least in trying to flatten
> potential nested cases? Though it seems to be more specific in how it
> handles the return values.
>
> Robert
>
>
There are a few important distinctions. See
https://github.com/erlang/eep/blob/master/eeps/eep-0049.md#elixir-like-patterns-in-with
for the full rationale compared to Elixir's *with *construct.

The TL:DR; is that their stuff is more general, but contains some
ambiguities that makes it weaker for error handling specifically. For
example in:

-spec fetch() -> {ok, iodata()}.
fetch() ->
    begin
        {ok, B = <<_/binary>>} <- f(),
        true <- validate(B),
        {ok, sanitize(B)}
    end.

If the value returned from f() is a list (a socket using list instead of
binary as an option), the expression will return early, the fetch()
function will still return {ok, iodata()} but you couldn’t know as a caller
whether it is the transformed data or non-matching content. This could
represent a major security risk allowing to bypass sanitization. The only
way to fix it is to have the 'else' block that contain all expected
possible erroneous values to make sure the "unexpected good but
non-matching values" do cause a failure while "actual expected errors" get
returned, which is tedious.

This problem is impossible with

-spec fetch() -> {ok, iodata()}.
fetch() ->
    begin
        B = <<_/binary>> <~ f(),
        _ <~ validate(B), % returns ok if valid
        {ok, sanitize(B)}
    end.

Due to the stricter matching rules on correct results.

I suspect Elixir folks don't run into that problem too often because their
pattern matching rules re-bind variables by default, so most cases that
could be "accidental non-matches" never show up, or otherwise mainly use
the pattern for side-effectful calls where they don't care for the good
value being returned.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://erlang.org/pipermail/eeps/attachments/20180920/dc0757b8/attachment.htm>