[erlang-questions] Exceptions vs Tagged Values

[Ulf Wiger]

Den 2006-11-11 01:41:55 skrev Robert Virding <robert.virding@REDACTED>:

> The problem is that I want to differentiate between different
> types of error/exceptions. I DON'T JUST want errors or JUST
> exceptions. Both have their place.

I think our recommendation (inasfar as there's been one) has been
to not throw exceptions at the end user. Some interface functions may
be intuitively written such that they either produce a correct
result or exit. Obviously, some OTP library functions do just
that, and it's usually when there is no sensible 'error' value
to present:

lists:reverse(foo) -> {error, 'eh?'}

One could of course argue that the compiler could throw an
exception if a module doesn't compile. That exception would
probably then be

compile:file(F, Opts) -> ... erlang:error(Errors)

How then the compiler goes about collecting the errors,
and not suddenly breaking on the first error, just because
it wants to avoid packing an error tuple, would of course
be up to the compiler designer. It's certainly not obvious
that throwing exceptions makes for clearer code, when you're
obviously going to continue searching for more errors anyway.

The problem in a large system (such as ...uh, the AXD 301),
is that you have tons of internal components that, in a sense
have managed interfaces between each other. Many of the sequences
run across several such component boundaries, but the division is
in a sense arbitrary - we may choose to divide things into blocks
because it makes more sense from a project perspective to do so,
it's all our code; it's all our environment, and the environment
is relatively well controlled.

There is then one rule in particular, that I feel is relevant to
the discussion:

"Trust internal users. Do not trust external users."

Since we trust users of internal interfaces to know what they're
doing, we can also devise the interfaces to reflect the
corresponding trust, that our component also does what it's
supposed to. If it doesn't, it should rightfully be an exception.

Not trusting external users also means that you expect them to
misuse the interface, and test all input. One can then also
assume a more bureaucratic stance and respond "Sorry, but you
haven't filled out the form correctly. Can't help you.
Have a good day."(*) - in Erlang/POSIX speak, abbreviated to e.g.
{error, einval}.

While "we" like this to be the default policy, there will be a
significant number of interfaces that really should return
with a slightly more gentle touch. The thing is, that all the
code that wraps case clauses around function calls, not only
is more verbose, but also risks hiding the error, rather than
throwing an exception as close to the original weirdness as
possible.

(*) For the human equivalent to throwing exceptions in user
interaction, I take great pleasure in watching "House, M.D.":
Effective, but nobody likes him much.

/Ulf W
-- 
Ulf Wiger