TSa <[EMAIL PROTECTED]> writes:
> HaloO,
>
> 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.
It asks the continuation? The information should be there. Consider a function
definition:
sub whatever(...) returns List {
throw ResumableException;
}
Then, assuming that caller returns continuation -- which is a pretty big
assumption, but which would be really cool -- $!.caller(1) would be a
continuation with an signature of (List $not_a_real_name). If the function can
return several types dependent on context, then the continuation's signature
would be the appropriate one for the context in which the function was
called. Monkeying with this kind of thing in code isn't necessarily a good
idea, but it's great for, for instance, having a top level exception catcher
that could (potentially) bring up an interactive shell with limited debugging
features which would allow you to inspect the running program and work out what
went wrong. Ruby on Rails already does something like this, with the added
wrinkle that, if it hits a breakpoint when running in the server it hands off
the interactive session to a console process rather than having you monkey with
it within your browser. A very neat trick and a remarkably powerful debugging
technique.
> The inocent foo() caller shouldn't bother about a quux() somewhere down the
> line of command. Much less of it innards.
>
> Think of receiving a 'shelf picker died of lung cancer' exception when you
> just ordered a book from your favorite book dealer. Irrespective of the
> seriousness to the shelf picker, but how would you expect a customer to
> handle such an exception?
I wouldn't, but I would expect that a programmer would find such an exception
very useful indeed.
--
Piers Cawley <[EMAIL PROTECTED]>
http://www.bofh.org.uk/
