Catch

classic Classic list List threaded Threaded
7 messages Options
Reply | Threaded
Open this post in threaded view
|

Catch

Fredrik Linder-3
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


Reply | Threaded
Open this post in threaded view
|

Catch

Lennart Ohman
Hi Fredrik and all other,

my personal experience is that the real problem is not syntactical.
(Well it is in some way since catch has two meanings...)
It is so called catch-and-throw-driven-programs. Programs where a
throw is placed very far away from its (many) matching catches.
The problem accelerates from the fact that if a lot of code is
encapsulated in a catch-and-throw, there are many potential errors
which will then by accident be caught in the catch (corresponding
to the throw).

/Lennart

Fredrik Linder wrote:

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

--
-------------------------------------------------------------
Lennart Ohman                   phone   : +46-8-587 623 27
Sjoland & Thyselius Telecom AB  cellular: +46-70-552 6735
Sehlstedtsgatan 6               fax     : +46-8-667 8230
SE-115 28 STOCKHOLM, SWEDEN     email   : lennart.ohman


Reply | Threaded
Open this post in threaded view
|

Catch

Fredrik Linder-2
In reply to this post by Fredrik Linder-3
Hi all

I forgot to mension why this proposal came up in the first place! In
core-erlang do they have a try-statement, and hence would it be attractive
to have it also in erlang, so that the compiler would not have to catch
everything everytime, but only those exceptions that are explicitly matched.
It was my impression that this could slightly speed up the compiled code, or
at least simplify translation between erlang and core-erlang.

To be able to do so must erlang define a way to differentiate between normal
excecution code and exception execution code, and this is not possible in
current erlang.

With the given proposal could differentiation between normal execution code
and exception execution code be made without having to introduce a new
statement.

An [erlang:]throw/0 could also be introduced to re-throw the current
exception, when caught.

The last part would also unify the syntax between recieve and case
statements. Is it totally wrong to see signals as exceptions between
processes?

/Fredrik

----- Original Message -----
From: "Fredrik Linder" <qtxfklr>
To: <erlang-questions>
Sent: Tuesday, November 20, 2001 3:44 PM
Subject: Catch


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



Reply | Threaded
Open this post in threaded view
|

Catch

Fredrik Linder-2
In reply to this post by Lennart Ohman
Hi Lennart and all

----- Original Message -----
From: "Lennart ?hman" <lennart.ohman>

> my personal experience is that the real problem is not syntactical.
> (Well it is in some way since catch has two meanings...)
> It is so called catch-and-throw-driven-programs. Programs where a
> throw is placed very far away from its (many) matching catches.

Personally I find catch-and-throw programming very clean and good,
especially in relation to the alternative - having error-return values.

> The problem accelerates from the fact that if a lot of code is
> encapsulated in a catch-and-throw, there are many potential errors
> which will then by accident be caught in the catch (corresponding
> to the throw).

I also recognise the problem of having a lot of catch-and-throw
encapsulations, however does this problem not arise from the fact that a
catch in erlang always catched everything, and there is no way to only catch
a particluar exception.

One of the benefits of the given proposal is that it would become possible
to have such constructs. It would also be possible to have catch-throw
encapsulation completely hidden within one module, without any .

(By the way, there are far more places to put a throw than a catch in ones
code.)

Best Regards
/Fredrik

This construct is probably safe for separating normal execution code from
exception execution code, but who programs in this fasion?

Ref = make_ref(),
case
    catch
    case <expr> of
        Match1 -> {Ref, normal_code}
    end
    of
    {Ref, Result} -> Result;
    Match2 -> exception_code
end




Reply | Threaded
Open this post in threaded view
|

Catch

Maurice Castro
Fredrik writes:

> I also recognise the problem of having a lot of catch-and-throw
> encapsulations, however does this problem not arise from the fact that a
> catch in erlang always catched everything, and there is no way to only catch
> a particluar exception.
>
> One of the benefits of the given proposal is that it would become possible
> to have such constructs. It would also be possible to have catch-throw
> encapsulation completely hidden within one module, without any .
>

Personally, I find the fact that catch catches everything to be a desirable
feature. This makes the handling of exceptions at a particular catch explicit.
When attempting to understand the behaviour of a program which uses exceptions
it is particularly desirable that the exceptions not propogate up the call
chain. Furthermore, if propogation is required, making it explicit warns the
programmer that this is the desired behaviour.

        Maurice Castro


Reply | Threaded
Open this post in threaded view
|

Catch

Robert Virding-4
In reply to this post by Fredrik Linder-3
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> 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
>


Reply | Threaded
Open this post in threaded view
|

Catch

Thomas Lindgren-3

More structured exceptions would be nice; add the
line number where the exception occurred while you're
at it.

It would also be generally useful to see the
actual arguments of the operation that caused the
exception as well, rather than 'badarg' or 'badmatch'
or whatever. (For pattern matching, showing the entire
pattern or clause head would be better than just the failing
match.)

-- Thomas

PS. Pardon my Outlook.