At 01:16 AM 8/16/00 -0600, Tony Olekshy wrote:
>The proposed omnibus Exceptions RFC uses the following three
>rules to guide it while unwinding through the clauses of a
>try statement.
Forgive me for eliding your explanation, but I find it a little opaque, and
it doesn't seem to explain how you get the exception stacking effect you
want. Let me advance a model which may be simpler. You can also assume
I'm thinking of using catch EXPR instead of except BLOCK => catch as I said
in my last message.
1. When an exception is thrown perl looks for the enclosing try block; if
there is none then program death ensues.
2. If there is an enclosing try block perl goes through the associated
catch blocks in order. If the catch criteria succeed (the exception class
matches one in a list, or a catch expression evaluates to true, or the
catch block catches everything), the catch block is executed. If the catch
block throws an exception, it becomes the 'current' exception (with a link
to the previous one), otherwise there is no longer a current exception.
3. Whether or not a catch block was executed, the finally block (I prefer
'continue') is now executed if there is one. If the finally block throws an
exception, it becomes the 'current' exception (with a link to the previous
one if there was one). At this point, if there is a current exception, go
to step 1.
This seems complete and IMHO easily understood.
>Now consider this case.
>
> try { } except { } => catch { }
> except { } => catch { }
> catch { }
>
>The potential problem is that if the first catch throws, then
>the second except will be testing against the $@ from the catch,
>not the $@ from the try. This can be avoided by using the
>following synatx from the proposed omnibus Exceptions RFC:
>
> try { }
>
> except { $@->any(... $_[0] ...) } => catch { }
> except { $@->any(... $_[0] ...) } => catch { }
>
> catch { }
>
>Is this a problem?
Yes, I think it breaks the intuitive model. Let's leave $@ out of the
discussion for now, since it implies a place to store an exception which is
unnecessarily global. throws() outside a try block are caught by the catch
blocks of the next enclosing try block. See above.
--
Peter Scott
Pacific Systems Design Technologies
