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?)


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)
>>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