[erlang-questions] Any wisdom to offer on "tagged return values"

[Joe Armstrong]

On Tue, May 5, 2009 at 12:20 AM, Robert Virding <rvirding@REDACTED> 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
error :-)



> Robert
>
> 2009/5/4 Tony Arcieri <tony@REDACTED>
>>
>> On Sat, May 2, 2009 at 3:50 PM, mats cronqvist <masse@REDACTED> 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
>> medioh.com
>>
>> _______________________________________________
>> erlang-questions mailing list
>> erlang-questions@REDACTED
>> http://www.erlang.org/mailman/listinfo/erlang-questions
>
>
> _______________________________________________
> erlang-questions mailing list
> erlang-questions@REDACTED
> http://www.erlang.org/mailman/listinfo/erlang-questions
>