Fredrik Linder fredrik.linder@REDACTED
Tue Nov 20 21:15:16 CET 2001

Hi Lennart and all

----- Original Message -----
From: "Lennart Öhman" <lennart.ohman@REDACTED>

> 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

Best Regards

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

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

More information about the erlang-questions mailing list