On Fri, Oct 07, 2005 at 05:23:55 +0100, Piers Cawley wrote: > "Peter Haworth" <[EMAIL PROTECTED]> writes: > > > On Wed, 5 Oct 2005 19:24:47 +0200, Yuval Kogman wrote: > >> On Wed, Oct 05, 2005 at 16:57:51 +0100, Peter Haworth wrote: > >> > On Mon, 26 Sep 2005 20:17:05 +0200, TSa wrote: > >> > > Piers Cawley wrote: > >> > > >>Exactly which exception is continued? > >> > > > The bottommost one. If you want to return to somewhere up its call > >> > > > chain, do: > >> > > > > >> > > > $!.caller(n).continue(42) > >> > > > >> > > Whow, how does a higher level exception catcher *in general* know > >> > > what type it should return and how to construct it? The innocent > >> > > foo() caller shouldn't bother about a quux() somewhere down the line > >> > > of command. Much less of its innards. > >> > > >> > Well said. > >> > >> No! Not well said at all! > > > > Sorry, I misread that. I thought I was agreeng with "how does a higher > > level exception catcher know what to change in order to make resuming the > > continuation useful?", especially in the light of Piers saying that the > > bottom-most exception should be the one resumed. > > I'm sorry, we appear to have lost some kind of context, the original example > given only had one exception thrown, but it got propagated up through a long > call chain. At no point did anything catch the original exception and > rethrow. If they had, you're absolutely correct in asserting that by default > things should resume from the point of the outermost rethrow. A brave > exception > catcher (or more likely programmer with a debugger) might want to crack that > exception open and examine its inner exceptions, but in general that's not > going to be safe.
It doesn't really matter since 'fail'ed exceptions will simply be converted to a "return with the continued value" when resumed, and the question of outer/inner scopes is really irrelevant - it's like tail calls. As for die - since there is no implicit returning in die, it might or might not make sense to try and resume. However, for most situations it still looks to me like 'die "foo"' could be treated as return in a way. Essentially throwing an error means that the function/method who threw it is giving up since it doesn't know how to resume. If the exception handler can find an alternative for that function, and replace the value, it's immediate caller should get the fixed value, since they are the ones who need the value. Functions which delegate exceptions are, again, just like tail calls. -- () Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker & /\ kung foo master: /me wields bonsai kittens: neeyah!!!!!!!!!!!!!!!!
pgp3KBtXh5Rua.pgp
Description: PGP signature
