Try/Cond
Francesco Cesarini
francesco@REDACTED
Wed Oct 22 08:39:04 CEST 2003
Yes, I agree that there are flaws in the semantics of catch and throw.
But in my 8 years of working with Erlang, only once did I see a problem
with them:
X = (catch foo(Y)),
ets:insert(bar, {Y, X}).
All the other times, we solved the problem with the simple design rule:
Do not use catch and throw.
With the introduction of OTP in 1996, I have never seen anyone use exit
in their code. The few catches and throws I came across were easily
rewritten into a more purely functional style.
Yes, it would have been nice with better separated semantics for exit,
catch and throw from the start, but I do not see the need to resolve
this issue now, considering that it is not causing problems. The issue
will not be resolved anyhow, as catch, throw and exit will still remain
in the language in the same format they exist in today. (Or is the plan
to remove some other feature when introducing try and cond?)
Regards,
Francesco
--
http://www.erlang-consulting.com
Richard Carlsson wrote:
>----- Original Message -----
>From: "Sean Hinde" <sean.hinde@REDACTED>
>To: "Richard Carlsson" <richardc@REDACTED>
>Cc: "Erlang Questions" <erlang-questions@REDACTED>
>Sent: Tuesday, October 21, 2003 9:15 PM
>Subject: Re: Try/Cond
>
>
>
>
>>So this is the same as:
>>
>>case catch scan(Fd) of
>>foo -> ...;
>>bar -> ...;
>>{throw, eof} ->
>>....;
>>Else -> exit(Else)
>>end.
>>
>>or am I missing something more subtle?
>>
>>
>
>Yes, with this "simulated try", you can't be sure that the
>term {throw, eof} was not just a value returned from the
>expression in the "catch", and more importantly, when you
>call "exit(Else)", you exchange the caught exception for
>a completely new one - often with different properties.
>
>For example, catching a "badmatch" error and re-throwing
>it with "exit" would change the exception so that it is not
>logged. Another possible mistake is catching a term originally
>thrown with "throw(X)" and re-throwing it using "exit(X)".
>
>To put it short: Erlang exceptions carry more information
>than most people think, and the old "catch" just wasn't
>constructed with this in mind - it destroys most distinctions.
>(One could say that it presents a very simple model to
>the user, by lying about the details.)
>
> /Richard
>
>
>
>
>
More information about the erlang-questions
mailing list