[erlang-questions] Any wisdom to offer on "tagged return values"
Tue May 5 00:20:03 CEST 2009
Erlang has always had exceptions! The problem is much more complex than
this. Always signaling an error would make coding extremely difficult,
almost as bad as always forcing you to check return values.
The problem is, of course, that what is an error can be very case specific.
In this case, whether you can find the tuple in the list or not is an error
depends on whether the tuple *should* be there or if you are checking *if*
it is there. Same thing, for example, with opening a file.
Always signaling an error would also tend to hide *real* errors from the
more testin type of errors. So even in this simple case it would be
difficult to see if the element was not there or for example you had a type
error, which always IS a *real* error. You would to wrap thins everywhere in
try's and try to look at the error type to determine what was happening. Big
Win there! (that was being sarcastic)
So, the problem is much more complex than just doing either or and libraries
have to try to be reasonable. Having different functions for different cases
is an easy way. Returning wrapped values makes it easy for the caller to
show what they consider an error. That being said I feel there are some
cases which are always errors. For example a bad type is always an error.
2009/5/4 Tony Arcieri <>
> On Sat, May 2, 2009 at 3:50 PM, mats cronqvist <> wrote:
>> My theory is that the people who wrote this "programming rule" were
>> (good) C programmers, and thus felt a need to check if the value
>> returned was ok before they dared use it.
> My theory is originally the Erlang VM didn't have exceptions, so this was
> the only way to do it, and for the sake of consistency has remained even
> after the advent of exceptions.
> Tony Arcieri
> erlang-questions mailing list
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the erlang-questions