Home > Archive > PERL POE > June 2005 > catching exceptions in sessions
You are viewing an archived Text-only version of the thread.
To view this thread in it's original format and/or if you want to reply to
this thread please [click here]
| Author |
catching exceptions in sessions
|
|
| Mathieu Longtin 2005-06-08, 9:04 pm |
| Hi,
is there a way in a POE::Session to put an eval { } around
all the states, and if an exception occurs, forward it to
another state?
Thanks
-Mathieu
__________________________________
Do you Yahoo!?
Yahoo! Mail - Find what you need with new enhanced search.
http://info.mail.yahoo.com/mail_250
| |
|
|
|
|
| Rocco Caputo 2005-06-08, 9:04 pm |
| On Tue, Feb 01, 2005 at 03:00:34PM -0600, Tim Klein wrote:
> Does POE::Exceptions work with POE::NFA, or only with POE::Session?
It is a subclass of POE::Session. There is no exceptions class built
atop POE::NFA.
POE::Exceptions was originally written as an experimental prototype so
people could evaluate it, comment upon it, and come up with a generic
mechanism for POE exceptions. We're still waiting for that general
pattern to emerge. :)
--
Rocco Caputo - http://poe.perl.org/
| |
| Mathieu Longtin 2005-06-08, 9:04 pm |
| Well, POE::Exception fits exactly what I wanted to do.
I just wish it was integrated in POE instead of being a
separate module.
-Mathieu
--- Rocco Caputo <rcaputo@pobox.com> wrote:
> On Tue, Feb 01, 2005 at 03:00:34PM -0600, Tim Klein
> wrote:
> POE::Session?
>
> It is a subclass of POE::Session. There is no exceptions
> class built
> atop POE::NFA.
>
> POE::Exceptions was originally written as an experimental
> prototype so
> people could evaluate it, comment upon it, and come up
> with a generic
> mechanism for POE exceptions. We're still waiting for
> that general
> pattern to emerge. :)
>
> --
> Rocco Caputo - http://poe.perl.org/
>
________________________________________
__________
Do You Yahoo!?
Tired of spam? Yahoo! Mail has the best spam protection around
http://mail.yahoo.com
| |
|
| -----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1
Rocco Caputo wrote:
| POE::Exceptions was originally written as an experimental prototype so
| people could evaluate it, comment upon it,
hell, i'm still waiting for the COMMENTS, let alone a pattern to emerge
from them. the module seemed to kill the conversation and i've never
figured out whether that meant that i hit a home run or totally scared
everyone off :)
- --
sungo
[url]http:// .org[/url]
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
iD8DBQFCAC3w5xrCYZCVAioRAv2GAKCfPoqoypo9
R/X9vw/VBDS89o1wSgCgjtai
JPQHB3HApJyqEl8pvRjqPzI=
=AOjt
-----END PGP SIGNATURE-----
| |
| Leif Gustafson 2005-06-08, 9:04 pm |
| Sungo wrote:
> hell, i'm still waiting for the COMMENTS, let alone a pattern to emerge
> from them. the module seemed to kill the conversation and i've never
> figured out whether that meant that i hit a home run or totally scared
> everyone off :)
I have some observations about the module. Please correct me if I'm
wrong or if I've misunderstood anything about the design of the module.
I like the idea of POE::Exceptions, but I feel it doesn't accurately
represent the way exceptions should be used. I think one of the biggest
problems is the fact that it uses a POE DIE signal to indicate an
exception has occured. I feel like this encourages programs to be
written that have a single "exception session" that handles exceptions
for the entire program. This is probably okay for small programs.
However, I'm not sure how easy it would be once you start adding
components in the mix that throw and/or catch exceptions. It seems to
me in this case there would be a good chance that the wrong session
might catch another sessions exception. In general, it would seem to
negate the modularity of components.
I think what we need is a way to KNOW where the exception is going to
go. With non-POE exceptions, when you throw an exception, you know
where the code is going to go (outside the eval in perl or in the catch
block in some other language). With the current module, one doesn't
neccessarily know who's going to catch the exception. Maybe we need the
kernel sending a predefined event to the parent of the session that
throws the exception (to represent a catch block in the calling
code)...I don't know.
Of course, another problem is that we can't rethrow exceptions. I think
this is an important concept in non-POE code.
--
LG
| |
| Mathieu Longtin 2005-06-08, 9:04 pm |
| Wait, the DIE signal is not sent directly to the session
that caused it?
--- Leif Gustafson <leifgust@yahoo.com> wrote:
> Sungo wrote:
>
> pattern to emerge
> and i've never
> totally scared
>
> I have some observations about the module. Please
> correct me if I'm
> wrong or if I've misunderstood anything about the design
> of the module.
> I like the idea of POE::Exceptions, but I feel it doesn't
> accurately
> represent the way exceptions should be used. I think one
> of the biggest
> problems is the fact that it uses a POE DIE signal to
> indicate an
> exception has occured. I feel like this encourages
> programs to be
> written that have a single "exception session" that
> handles exceptions
> for the entire program. This is probably okay for small
> programs.
> However, I'm not sure how easy it would be once you start
> adding
> components in the mix that throw and/or catch exceptions.
> It seems to
> me in this case there would be a good chance that the
> wrong session
> might catch another sessions exception. In general, it
> would seem to
> negate the modularity of components.
> I think what we need is a way to KNOW where the exception
> is going to
> go. With non-POE exceptions, when you throw an
> exception, you know
> where the code is going to go (outside the eval in perl
> or in the catch
> block in some other language). With the current module,
> one doesn't
> neccessarily know who's going to catch the exception.
> Maybe we need the
> kernel sending a predefined event to the parent of the
> session that
> throws the exception (to represent a catch block in the
> calling
> code)...I don't know.
> Of course, another problem is that we can't rethrow
> exceptions. I think
> this is an important concept in non-POE code.
>
> --
> LG
>
__________________________________
Do you Yahoo!?
Take Yahoo! Mail with you! Get it on your mobile phone.
http://mobile.yahoo.com/maildemo
| |
| Dylan Hardison 2005-06-08, 9:04 pm |
| One wonders if:
$SIG{__DIE__} = sub {
die $_[0] unless defined $^S;
$poe_kernel->yield('_die');
};
would work.
/me goes off to test.
| |
| Rocco Caputo 2005-06-08, 9:04 pm |
| On Wed, Feb 02, 2005 at 03:49:03PM -0500, Dylan Hardison wrote:
> One wonders if:
>
> $SIG{__DIE__} = sub {
> die $_[0] unless defined $^S;
> $poe_kernel->yield('_die');
> };
>
> would work.
That has a (possibly) undesirable effect of catching die() when called
by POE::Kernel itself. Maybe adding
die unless $poe_kernel;
die if $poe_kernel->get_active_session() == $poe_kernel;
would solve that.
--
Rocco Caputo - http://poe.perl.org/
| |
| Leif Gustafson 2005-06-08, 9:04 pm |
| Mathieu Longtin wrote:
> Wait, the DIE signal is not sent directly to the session
> that caused it?
You're probably right, and so most of my observations should be ignored!
Though it's probably still important to make sure who sent the DIE
signal, otherwise your child sessions who might be handling their own
exceptions might catch yours (signals are propogated to children first,
right??).
--
LG
|
|
|
|
|