Catch

[Robert Virding]

My personal view to this is definetely NO NO NO NO!

I think it would be a big mistake to try and combine different
semantical elements in one syntactic construction.  Perhaps I am just
getting old but I think it is much cleaner for each construct to do
ONE thing.  Also much easier to explain to people.  And I am pretty
certain that you could get some pretty funny cases here.

Erlang started out small and clean (yeah, yeah I know) and whatever is
added should remain that way.  case-catch and receive-catch definitely
aren't clean.

This said I think that try would be a Good Thing and it is on the
way.  With the selection method you can easily handle checking for
specific errors.  Although I agree with Maurice Castro that you should
probably be careful it just catching some faults and implicitly
passing the rest on.  Another problem with try is that all the exit
values aren't really defined yet and this would have to be done.  This
would also entail defining what an exit value looks like and this has
not been done yet.  Although the system consistenly gives
{What,Where}.  I think.

Robert

Fredrik Linder <qtxfklr@REDACTED> writes:
>Hi
>
>At the Erlang Workshop in Florence did a discussion about separating
>code for normal execution from code for exception(al?) execution take
>place.
>
>Now I am wondering what the Erlang community think about a proposal that
>came up.
>
>The proposal is to extend where a catch might be placed. Note that the
>current use of catches could still be valid.
>
>Proposal:
>
>case <expr> of
>    NormalMatch1 ->
>        blabla;
>    NormalMatch2 ->
>        blabla
>catch
>    {'EXIT', Reason} ->
>        blabla;
>    ExceptionMatch2 ->
>        blabla
>end
>
>If this feels like a good way of doing it, then maybe also extend this
>to receive statements:
>
>receive
>    NormalMatch ->
>        blabla
>after
>    Time ->
>        blabla
>catch
>    {'EXIT', Pid, Reason} ->
>        blabla;
>    SignalMatch ->
>        blabla
>end
>
>By introducing an 'EXIT' record could this be extended further:
>
>-record('EXIT', {pid, reason}).
>
>recieve|case <expr> of
>    NormalMatch ->
>        blabla
>catch
>    #'EXIT'{} ->
>        blabla;
>    #'EXIT'{pid = Pid} ->    % In a case statement is Pid == self()
>        blabla;
>    #'EXIT'{reason = Reason} ->
>        blabla
>end
>
>The last suggestion could be implemented as syntactical suger (I guess).
>
>/Fredrik
>