At 11:49 AM 8/16/00 -0400, John Porter wrote:
>Glenn Linderman wrote:
> >
> > More seriously, I agree there is no need for a "try" keyword... it just
> > starts a block, which could just as well be any other block.
>
>This makes especially good sense if the catch{} is INSIDE the relevant
>block, rather than following it.
>
>Because without "try" (or its equivalent), there would be ambiguity
>as to what block the second catch below is applying to:
>
> qc/try/ {
qc?
> might_throw_E1_or_E2();
> }
> catch E1 {
> might_throw_E2();
> }
> catch E2 {
> # where did this E2 come from?
> }
I see where the ambiguity arises. My mental model is that try blocks nest,
and since the catch E1 block is not inside the try block, anything it
throws will not be caught by any of that try block's catch blocks. So E2
thrown from catch E1 could never be caught in the catch E2 block above.
>But no such ambiguity exists here:
>
> qc/try/ {
> might_throw_E1_or_E2();
> catch E1 {
> might_throw_E2();
> }
> catch E2 {
> # we know exactly where this E2 came from!
> }
> }
It has an IMHO more serious ambiguity I have already pointed out.
--
Peter Scott
Pacific Systems Design Technologies
