On Tue, Sep 27, 2005 at 07:29:48 +0100, Nigel Hamilton wrote: > >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?
The exception mechanism is an event system that is typically used
for nothing but errors, but is much more extensible than that.
In fact, exceptions are nothing more than continuations really.
The CATCH block 'temp' sets a global exception handler continuation,
and die is simply
sub die (*$a) { &*EXCEPTION_HANDLER.(*$@) }
Also, it's hard for a library writer to consistently decide what is
an error and what isn't. It's also too much trouble. If every
library had severity levels, things would be complicated for small
scripts.
On the other hand, whenever an event that is not what 90% of the
flow control should be does occur, exceptions let you delegate the
behavior of how to deal with this to other code, specifically the
code that called you.
It just happens that the default &*EXCEPTION_HANDLER continuation is
essentially
print STDERR "@_";
exit $bad_error_code;
> Hear, hear.
>
> Isn't just an exception a naughty event? But when you think about it, isn't
> all programming
> about suggesting events and handling what happens next?
Well, not necessarily. It's an event that is exceptional, i.e. not
normal.
99% of non normal events are errors, but we routinely use exceptions
for timeout, etc.
{
temp $SIG{ALRM} = { die "timeout"; } # we need a better
mechanism for this in perl 6, IMHO
alarm 10;
connect(...);
CATCH {
when "timeout" {
$!.resume if prompt("The remote party does not
seem to be responding. Keep trying?");
}
default { $!.rethrow }
}
}
Timing out is not an error unless the user decides it is. Normally
the user would have to decide beforehand when lack of responsiveness
becomes an error, but with a system like this the user can be
prompted on a case by case basis to decide whether it's an error or
not.
> Is there a way of integrating Perl's natural ability to stay on topic ($_)
> with exception
> handling, and event handling?
As I see it continuations are a way to get back on topic...
Hey, 3rd party, the underlying thingy told me that yadda
yadda... If you can fix it, here's what you do next.
This is why I proposed the idea.
I would like to expand on your ideas though - the program is layered
with a delegation hierarchy... The lowest level agent is the
operating system. On the other side, the user makes a query to the
program which makes a query to it's first level handler, that uses a
library, that uses another and so on and so forth.
In a sense, the third party you mention is always the caller of a
given block of code, with the other two parties being the called
level, and the level below it.
Intervention on behalf of the third party can be delegated upwards
if this layer does not have enough policy on event handling. The
only level which really knows how to behave under any event
(hopefully ;-) is the user.
> Just some thoughts ...
Good post!
--
() Yuval Kogman <[EMAIL PROTECTED]> 0xEBD27418 perl hacker &
/\ kung foo master: /me does a karate-chop-flip: neeyah!!!!!!!!!!!!!!
pgpFk63eGjRwQ.pgp
Description: PGP signature
