[erlang-questions] Exceptions vs Tagged Values

[Robert Virding]

Hello Ulf,

All I can say is "I agree completely". It must be, of course, the 
application and its solution which decides where and how errors are to 
be handled.

What I was protesting against was the dogmatic :-) view that all library 
functions should always generate exceptions. Which is as wrong as saying 
that never should.

Your point about internal and external users is one that can never be 
stated too many times.

Robert

Ulf Wiger wrote:
> 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