You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@couchdb.apache.org by Jason Smith <jh...@couchone.com> on 2010/12/05 09:19:23 UTC
Re: svn commit: r1042260 - /couchdb/trunk/src/couchdb/couch_native_process.erl
On Sun, Dec 5, 2010 at 6:06 AM, <ja...@apache.org> 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
Re: svn commit: r1042260 - /couchdb/trunk/src/couchdb/couch_native_process.erl
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Dec 6, 2010 at 10:48 AM, Adam Kocoloski <ko...@apache.org> wrote:
> On Dec 6, 2010, at 10:22 AM, Paul Davis wrote:
>
>> On Mon, Dec 6, 2010 at 10:19 AM, Adam Kocoloski <ko...@apache.org> wrote:
>>> On Dec 5, 2010, at 5:34 AM, Paul Davis wrote:
>>>
>>>> On Sun, Dec 5, 2010 at 3:19 AM, Jason Smith <jh...@couchone.com> wrote:
>>>>> On Sun, Dec 5, 2010 at 6:06 AM, <ja...@apache.org> 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
>>>
>>>
>>
>> That's not bad. I've never seen "try F() of" before. Is it new or am I blind?
>
> Dunno. It's been around as long as I remember. One thing to be careful of - the statement you wrote actually allows a user to catch exceptions from functions called in the body of the try clause, e.g.
>
> try (case Fun() of
> Val1 -> G();
> Val2 -> bar
> end) catch
> ExceptionThrownByG -> ok
> end
>
> whereas the "try F() of" syntax will not catch anything thrown by G(). This has burned me before.
>
> Adam
>
>
Ouch. I bet that was an exercise in debugging fun.
Re: svn commit: r1042260 - /couchdb/trunk/src/couchdb/couch_native_process.erl
Posted by Adam Kocoloski <ko...@apache.org>.
On Dec 6, 2010, at 10:22 AM, Paul Davis wrote:
> On Mon, Dec 6, 2010 at 10:19 AM, Adam Kocoloski <ko...@apache.org> wrote:
>> On Dec 5, 2010, at 5:34 AM, Paul Davis wrote:
>>
>>> On Sun, Dec 5, 2010 at 3:19 AM, Jason Smith <jh...@couchone.com> wrote:
>>>> On Sun, Dec 5, 2010 at 6:06 AM, <ja...@apache.org> 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
>>
>>
>
> That's not bad. I've never seen "try F() of" before. Is it new or am I blind?
Dunno. It's been around as long as I remember. One thing to be careful of - the statement you wrote actually allows a user to catch exceptions from functions called in the body of the try clause, e.g.
try (case Fun() of
Val1 -> G();
Val2 -> bar
end) catch
ExceptionThrownByG -> ok
end
whereas the "try F() of" syntax will not catch anything thrown by G(). This has burned me before.
Adam
Re: svn commit: r1042260 - /couchdb/trunk/src/couchdb/couch_native_process.erl
Posted by Paul Davis <pa...@gmail.com>.
On Mon, Dec 6, 2010 at 10:19 AM, Adam Kocoloski <ko...@apache.org> wrote:
> On Dec 5, 2010, at 5:34 AM, Paul Davis wrote:
>
>> On Sun, Dec 5, 2010 at 3:19 AM, Jason Smith <jh...@couchone.com> wrote:
>>> On Sun, Dec 5, 2010 at 6:06 AM, <ja...@apache.org> 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
>
>
That's not bad. I've never seen "try F() of" before. Is it new or am I blind?
Re: svn commit: r1042260 - /couchdb/trunk/src/couchdb/couch_native_process.erl
Posted by Adam Kocoloski <ko...@apache.org>.
On Dec 5, 2010, at 5:34 AM, Paul Davis wrote:
> On Sun, Dec 5, 2010 at 3:19 AM, Jason Smith <jh...@couchone.com> wrote:
>> On Sun, Dec 5, 2010 at 6:06 AM, <ja...@apache.org> 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
Re: svn commit: r1042260 - /couchdb/trunk/src/couchdb/couch_native_process.erl
Posted by Paul Davis <pa...@gmail.com>.
On Sun, Dec 5, 2010 at 3:19 AM, Jason Smith <jh...@couchone.com> wrote:
> On Sun, Dec 5, 2010 at 6:06 AM, <ja...@apache.org> 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.