[erlang-questions] Re: atoms used as status info, 'constants' etc
Dave Pawson
dave.pawson@REDACTED
Tue Aug 18 13:16:07 CEST 2009
2009/8/18 Witold Baryluk <baryluk@REDACTED>:
>>
>> My problem is a function that should return, say, a record, yet
>> the sought record does not exist?
>> Return a 'dummy' / null record or
>> Just a status value?
>> Groking in the case would be by the Erlang code rather
>> than the user.
>>
>> suggestions on how to handle this please?
> Generally it depends. If there is good default value, you can use
> "dummy" record, but mostly you want to distinguish beetween existing and
> not existing data.
>
> If you know that you always return record, anything which isn't record,
> like atom 'notfound', or 'error', or {error, not_found} will be
> sufficient, because in somewhere on calle side you will match returned
> value to the record, and this will crash (which is good).
I'd prefer not to crash and burn here, since the selection is based on
user input which could contain a typo.
>
>
>
> There are 4 main conventions in case of returning general values:
>
> 1. something which is distinguishable, because of type:
> return Tuple | false (like list:keyfind/3)
> or {ok, Value} | error (like dict:find/2)
> or {value, Value} | none (like gb_trees:lookup/2)
This is the example that's been bothering me.
Looking for a tuple, if not found, I've been returning false.
> 2. something which can be confused with value:
> return Value | undefined (erlang:get/1)
> or none | Value (like proplists:lookup/2)
> 3. throw exception if record is not found (like dict:fetch/2,
> orddict:fetch/2)
> 4. provide argument for default return value, (like proplists:lookup/3).
Thanks for those Witold.
regards
--
Dave Pawson
XSLT XSL-FO FAQ.
Docbook FAQ.
http://www.dpawson.co.uk
More information about the erlang-questions
mailing list