"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/
