"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. The scary syntax proposed above is, again, the sort of thing that might be useful in a debugger "I don't really care about the inner workings of these helper functions, I just want 'open' to return this mocked handle." (actually in that case, being able to do $!.caller(&open).continue(MockIO.new), where 'caller &open' looks up the call chain for the lowest call to open and returns that continuation would be rather neat) > The highest level exception is the only one a caller has any right to deal > with, but even then it doesn't really know what will happen if it resumes > some random continuation attached to the exception. Oh stop with the 'rights'. And it's not dealing with a 'random' continuation, if it's going to resume it should be damned careful about which exceptions it resumes from; you don't just go around doing CATCH {...; $!.continue(...)}, you do CATCH SomeSpecificKindOfResumableException { ...; $!.continue(...)}. And, in general, you don't do that either, because in the average program you catch the exception at a point where you can simply return a sensible default to your caller. Resumable exceptions come into their own, however, when you're debugging. I can envisage doing: perl6 -debug::on::error some_script And have it run along happily until an exception gets propagated up to the top level, at which point the debugger swings into action and uses the continuation to tunnel back to the point at which the exception was thrown so the programmer can inspect the program state, possibly fix things up, return something sensible and carry on. >> CATCH { >> when some_kind_of_error { >> $!.continue($appropriate_value_for_some_kind_of_error) >> } >> } > > That just gives me the willies, I'm afraid. It doesn't amuse me that much, unless whatever generates $appropriate_value_for_some_kind_of_error is very, very smart indeed. But, as I've said above, that's not really where resumable exceptions shine. -- Piers Cawley <[EMAIL PROTECTED]> http://www.bofh.org.uk/