[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