[erlang-questions] Package Support/Use

[Richard Carlsson]

Thomas Lindgren wrote:
> Regarding exceptions vs tagged tuples, I theoretically
> prefer exceptions but have found that I often need to
> use tagged tuples in practice. If I instead will have
> to wrap calls in catch to figure out and handle
> (usually undocumented) exception values, not a
> terrible lot has been gained.

Exceptions need to be documented as part of the function interface. And 
yes, this information can be tricky both to get right in the first 
place, and to keep up to date. But it must be done.

In fact, the problem is just another instance of the problem of 
returning values that you get from a call to some library function: if 
the library function is updated, so that it might suddenly yield a value 
that previous versions would never return, then your own function can 
suddenly also return this value (unless you check the return values of 
all functions you call, and do ...well, something, about it).

If you (anyone) thinks this does not happen in statically typed 
languages, think again: If a function is declared to return 'int', but 
actually returns only a subset of int, within a certain range (perhaps 
error codes), the compiler will not be able to check if a caller is 
expecting values within that range. Hence, your function, nicely 
documented to return values in the range 1-100, might suddenly return 
101. If you think enums or range types can fix this, try it with strings 
instead of integers. The only way to guarantee that you pass on exactly 
the data you claim to do, is to run a complete check for well-formedness 
on it (this can be done in assertions or pre/postconditions), or to 
always build your own return values from scratch (as a function of what 
the library function returned).

The angst over exceptions as part of function signatures in the Java 
world is precisely because people are suddenly confronted with a lot 
more of this kind of dynamic typing than they have been used to: In 
Java, what class of exceptions should you say that your function might 
throw? You probably can't change the interface later. If you would need 
to add a call to some library function, that might throw an exception 
that is outside the class that you declared, you're stuck handling it 
somehow (perhaps by throwing a different exception that fits your 
interface). Exceptions are a side-band transfer mechanism, and making 
exceptions part of the function prototype does not interact well with 
evolution of code. C# probably made a better decision.

Enough ranting for now,

	/Richard