Throw or return a tuple
Mats Cronqvist
mats.cronqvist@REDACTED
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