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. 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?
To me exceptions are to be handled with respect to the service
the scope invoked. In my example I would conclude that the book dealer has
more than one shelf picker under contract and just re-issue the order.
Well, or buy it elsewhere. In other words if the task at hand is
buying a certain book, exception handling means iterating all viable
sources with the assumption that the most convenient one *usually* delivers.
Otherwise I would code an iteration over the sources right away.
And handling user errors in a GUI application is a task for event handling,
*not* exception handling. I agree that both mechanisms share large parts
of the infra-structure supporting them. But I make a strong conceptual
distinction between them.
Which leads to the question, does Perl6 have or need a build-in event
system on the language level?
--
$TSa.greeting := "HaloO"; # mind the echo!
