On Dec 5, 2010, at 5:34 AM, Paul Davis wrote:
> On Sun, Dec 5, 2010 at 3:19 AM, Jason Smith <[email protected]> wrote:
>> On Sun, Dec 5, 2010 at 6:06 AM, <[email protected]> wrote:
>>> + case catch Fun(Doc, Req) of
>>> + true -> true;
>>> + false -> false;
>>> + {'EXIT', Error} -> ?LOG_ERROR("~p", [Error])
>>> + end
>>
>> The O'Reilly book _Erlang Programming_ suggests that catch expressions
>> (the older form before try...catch came out) are not as elegant as
>> try...catch.
>>
>> http://books.google.com/books?id=Qr_WuvfTSpEC&pg=PA74&lpg=PA74&source=bl&ots=aK-DfyxREb&sig=LA1Fi-lSKEPJNvMFdp0kXzOxDg8&hl=en&ei=W0T7TJLpMY_QrQffr4HBCA&sa=X&oi=book_result&ct=result&resnum=1&ved=0CBIQ6AEwAA#v=onepage&q&f=false
>>
>> Also Joe Armstrong's book states that you lose a lot of precision
>> analyzing the cause of an error.
>>
>> FYI.
>>
>> --
>> Jason Smith
>> CouchOne Hosting
>>
>
> I'm not sure about the book's definition of elegant, but:
>
> case (catch Fun()) of
> Val1 -> foo;
> Val2 -> bar;
> {Error, Reason} -> other
> end
>
> Seems more readable than:
>
> try
> case Fun() of
> Val1 -> foo;
> Val2 -> bar
> end
> catch
> throw:{Error, Reason} -> other
> end
>
> Its true that you end up collapsing the Error and Response domains
> into a single namespace, but in general, most things don't look like
> errors.
It can be made simpler:
try Fun() of
Val1 -> foo;
Val2 -> bar
catch
{Error, Reason} -> other
end
