Peter Scott wrote:
>
> qc?
A proposed form of in-line comment!
> > qc/try/ {
> > 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.
I was working from the assumption that any block could be a try block,
as long as it has catches attached to it.
In this case, catch blocks CAN NOT daisychain -- unless we want later
catches to also catch from preceding catches in the chain ... and I
don't think we do. (Do we?)
Now, I'm suggesting that allowing any block to be a try block, if it
has at least one catch attached to it... (hmm. "string"? :-) ... is a
Good Idea; but it would thus *require* a different syntax for specifying
the associated catches.... As in:
> > 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.
It does? Which one was that? That the semantics of code following
a catch is not defined? My answer to that was simply, Define it.
--
John Porter
Aus tiefem Traum bin ich erwacht.
