Try/Cond

[Joe Armstrong]

On Wed, 22 Oct 2003, Francesco Cesarini wrote:

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

  What - you're nuts
 
> 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.

  My code has loads of exits.

  The golden rule is "let it crash" - quite often code will crash
with a less-than-helpful (TM) diagnostic. Here I always write

	exit(<<some helpful diagnostic>>)

  The more I program the more I use exit - as soon as I don't know what to
do I instinctively write exit(...) - this is a reflex reaction.

  There is no way of getting a non-local return from a function if you
do not use catch and throw.

  Pleeeese teach you students the correct way to use catch/throw/exit -
this will lead to much cleaner code than if they try religiously to avoid
their use.

   /Joe

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