[erlang-questions] Any wisdom to offer on "tagged return values"
Wed May 6 09:25:15 CEST 2009
On Tue, May 5, 2009 at 12:20 AM, Robert Virding <> wrote:
> 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.
Apart from the case in a test suit that checks that badly typed
programs do generate the required error - in this case it's not an
> 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
> erlang-questions mailing list
More information about the erlang-questions