Throw or return a tuple

Mats Cronqvist <>
Tue Aug 16 16:38:26 CEST 2005



Roger Price wrote:
> On Tue, 16 Aug 2005, Mats Cronqvist wrote:
> 
> 
>>   throw an exception.
>>personally, i believe that returning {ok,R}/{error,R} is ALWAYS wrong.
>>e.g. file:open/2; as it is now, it will return {error,R} if there is
>>some system resource missing (truly exceptional), or if you pass it bad
>>data (e.g. a file that does not exist). in either case it should throw.
>>i wonder where the {error,R} idiom came from... but there definitely
>>seems to be a move away from it.
> 
> 
> I seems to me that there is place for both {error,Reason}, or better,
> {refused,R}, and exceptions.  Perhaps the criteria is that {error,R} is
> for situations that may occur in the normal course of business which
> prevent the function from completing, and exceptions are for things that
> are not expected in normal business.
> 
> Examples: File permissions do not allow access - {refused,R}
>           File system is on fire/has been stolen/power off - exception
>                             (Don't laugh, I've had these things happen)
> 

   well, i disagree.
   I want to be able to write code like:
process_data(file:read(file:open(...),...))
   the {ok,R} idiom prevents me from doing that(*).
   as for your example; if you're trying to access a file in a way that the file 
permissions disallow you're passing bad data. either you know that the file 
should have the right permissions, or you should check them with 
file:read_file_info before trying to open the file.
   the file:open/2 API looks like C to me; it returns a status code and a value, 
the interpretation of the value depends on the status code. not that there's 
anything wrong with C....

   mats

(*) so i have to write functions like this (pseudo-code);
sane_open(N,P) ->
   {{ok,FD},N} = {file:open(N,P),N},
   FD.



More information about the erlang-questions mailing list