Throw or return a tuple

orbitz@REDACTED orbitz@REDACTED
Sat Aug 13 22:58:47 CEST 2005


The try/catch syntax seems to be a lot ebtter than case catch.  Does it 
still have some common limitations that one should watch out for?


On Aug 13, 2005, at 3:25 AM, Ulf Wiger wrote:

> Den 2005-08-13 06:23:05 skrev <orbitz@REDACTED>:
>
>> I find myself often confused about which to do, should I throw an 
>> exception when an error happens in a function or always go with 
>> returning {ok, Value} or {error, Whatever}.
>
> This has been discussed now and then on the list.
> I think the cleanest way to program is to have functions
> that either return a good value or throw an exception
> (amendments to the rule will follow).
>
> Traditionally, there have been some problems with
> debugging this style of programming, but the problems
> are being addressed, e.g. with the new 'try' construct.
>
> Coupled with this is the 'let it crash' philosophy
> (http://www.google.com/search?&q=%22let+it+crash%22+erlang)
>
> A place where it's appropriate to wrap return values is
> for example:
>
> dict:read(Key) -> Value | exit()
> dict:search(Key) -> {found, Value} | not_found
>
>> Some people seem try to tell me that I should use {error, Value} and 
>> "get out of your OO mindset with exceptions".  But I think that is 
>> bull.
>
> I agree.
>
>
> One problem with always wrapping return values is that
> you get a lot of code like this:
>
> case foo(...) of
>    {ok, Result} ->
>       ...,
>       case bar(...) of
>          ...
>       end;
>    {error, Reason} ->
>       {error, Reason}
> end.
>
> That is, the most common situation is that you can't
> handle the error return value where it first occurs,
> and just pass it on to the caller. Throwing exceptions
> is a much better way to accomplish this.
>
> /Uffe
> -- 
> Ulf Wiger
>




More information about the erlang-questions mailing list