Front page | perl.perl6.language |
Postings from October 2005
From: Yuval Kogman
October 7, 2005 03:34
Message ID: 20051007103411.GQ23889@woobling.org
On Fri, Oct 07, 2005 at 05:23:55 +0100, Piers Cawley wrote:
> "Peter Haworth" <firstname.lastname@example.org> 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
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
() Yuval Kogman <email@example.com> 0xEBD27418 perl hacker &
/\ kung foo master: /me wields bonsai kittens: neeyah!!!!!!!!!!!!!!!!