Try/Cond

[Peter Lund]

I think catch/throw are useful when parsing.

I find catch very useful when parsing binaries or strings. This
enables me to write the parser in a very offensive manner and then
catch possible deviations from the correct format with a catch. If
I find a problem deep inside the parse algorithm it is also very
convinient to just throw and then let the catch-statement catch it,
instead of attempting to return fault information back through the
entire function call chain. That would really be a hazzle...

/Peter

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