Peter Scott wrote:
>
> I still think the explanation can be made simpler with fewer
> forward references. I'll have another try: [snip, but save]
>
> I note that under these rules it would be possible to have
> "try { ... } finally { }" with no catch blocks. I guess
> that's okay.
Have I got n
At 09:12 PM 8/16/00 -0600, Tony Olekshy wrote:
>Executive summary: I no longer want catch blocks to "daisy chain"
>after a exception is thrown in a catch block. Thanks to everyone
>who has helped me see the light on this.
I'm not sure what you mean by "daisy chain". I have been taking it to mean
At 11:05 PM 8/16/00 -0400, Chaim Frenkel wrote:
> > "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
> >> Also a use (within main or if it can work lexically) that would mean
> >> die_if_exception_thrown. Would treat the main routine as if it were
> >> wrapped in a try block that doesn't catch
Graham Barr wrote:
>
> On Wed, Aug 16, 2000 at 10:19:53AM -0400, Chaim Frenkel wrote:
> >
> > I would say that outside of the try block all throws are caught if
> > at all by the wrapping try. So that throws propogate outward. Never
> > back within itself.
>
> Agreed.
Throws propagate *forward*
Executive summary: I no longer want catch blocks to "daisy chain"
after a exception is thrown in a catch block. Thanks to everyone
who has helped me see the light on this.
Peter Scott wrote:
>
> At 01:16 AM 8/16/00 -0600, Tony Olekshy wrote:
> >
> > The proposed omnibus Exceptions RFC uses the f
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> At 07:10 PM 8/16/00 -0400, Chaim Frenkel wrote:
>> > "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>>
PS> 1. When an exception is thrown perl looks for the enclosing try block; if
PS> there is none then program death ensues.
>>
>>
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> Okay, :-) Got a better syntax? Would you want the option of
PS> throwing up n (> 1) levels?
I've seen the term SIGNAL vs. RAISE used.
I don't think we should. That gives the callee too much intimate
knowledge of the caller.
Lets keep
At 07:06 PM 8/16/00 -0400, Chaim Frenkel wrote:
> > "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>
> >> There is one case to be considered, what if the try block wishes
> >> to avoid its own catch clauses, and start the unwinding with the
> >> uplevel try block.
>
>GB> Can you think of a ti
At 07:10 PM 8/16/00 -0400, Chaim Frenkel wrote:
> > "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
>
>PS> 1. When an exception is thrown perl looks for the enclosing try block; if
>PS> there is none then program death ensues.
>
>Err, if there isn't one. Don't throw the exception. Stop process
> "PS" == Peter Scott <[EMAIL PROTECTED]> writes:
PS> 1. When an exception is thrown perl looks for the enclosing try block; if
PS> there is none then program death ensues.
Err, if there isn't one. Don't throw the exception. Stop processing but
don't throw. You are imposing a style on your
> "GB" == Graham Barr <[EMAIL PROTECTED]> writes:
>> There is one case to be considered, what if the try block wishes
>> to avoid its own catch clauses, and start the unwinding with the
>> uplevel try block.
GB> Can you think of a time you would want that ?
Here's one. If the catch blocks t
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
On Wed, Aug 16, 2000 at 11:49:03AM +0100, Graham Barr wrote:
> if any of the catch or finally throws, it is caught by a
> try {} block up the stack.
>
> Keep It Simple
What he said.
-Scott
--
Jonathan Scott Duff
[EMAIL PROTECTED]
On Wed, Aug 16, 2000 at 10:19:53AM -0400, Chaim Frenkel wrote:
> I would say that outside of the try block all throws are caught if
> at all by the wrapping try. So that throws propogate outward. Never
> back within itself.
Agreed.
> There is one case to be considered, what if the try block wish
I would say that outside of the try block all throws are caught if
at all by the wrapping try. So that throws propogate outward. Never
back within itself.
There is one case to be considered, what if the try block wishes
to avoid its own catch clauses, and start the unwinding with the
uplevel try
On Wed, Aug 16, 2000 at 01:16:26AM -0600, Tony Olekshy wrote:
> try { } finally { } catch { }
I don not see ht epoint of this ?
IMO, it should be simple.
try { }
catch Class { }
catch { }
finally { }
If try throws it is caught by the catch blocks
finally is always run
if any of
The proposed omnibus Exceptions RFC uses the following three
rules to guide it while unwinding through the clauses of a
try statement.
Rule 1: Uncaught Exceptions Propagate
At the end of the try statement, you are going to continue
unwinding up another level if *anything* threw, *unless*
17 matches
Mail list logo
