On Fri, Sep 28, 2001 at 01:01:33PM -0700, Rob Bloodgood wrote:
>
> > -----Original Message-----
> > From: Rocco Caputo [mailto:[EMAIL PROTECTED]]
> > Sent: Friday, September 28, 2001 11:58 AM
> > To: Rob Bloodgood
> > Subject: Re: Silent exits
> >
> >
> > On Fri, Sep 28, 2001 at 11:27:35AM -0700, Rob Bloodgood wrote:
> > > >
> > > > Sounds like an external condition to me, but maybe not. Turn on
> > > > ASSERT_DEFAULT, too... that'll enable all sorts of internal
> > > > consistency checks within POE::Kernel. Maybe it'll catch a bug...
> > >
> > > AHH!! Success!!!
> >
> > [...]
> >
> > > So yesterday I figured, what the hay, right? Turned on Event
> > at the same
> > > time as ASSERT_DEFAULT.
> > >
> > > Well, my next excecution revealed (interspersed in the ASSERT messages):
> >
> > ... ASSERT messages? There should be no ASSERT messages unless the
> > program dies. Maybe you still have TRACE_something on?
>
> ASSERT_DEFAULT messages:
>
> Sep 28 12:07:54 devel qd[5122]: a '_child' state was sent from
> /usr/lib/perl5/site_perl/5.005/POE/Kernel.pm at 1358 to session 7, but
> session 7 has neither that state nor a _default state to handle it
> Sep 28 12:07:54 devel last message repeated 2 times
> Sep 28 12:07:54 devel qd[5122]: a '_child' state was sent from
> /usr/lib/perl5/site_perl/5.005/POE/Kernel.pm at 1335 to session 7, but
> session 7 has neither that state nor a _default state to handle it
> Sep 28 12:07:54 devel last message repeated 2 times
>
> I checked twice, I do NOT have TRACE_EVENTS enabled (which is the only
> TRACE_* that appears in my program files, sez grep).
Ah, you're right. ASSERT_DEFAULT turns on
POE::Session::ASSERT_DEFAULT, which enables
POE::Session::ASSERT_STATES, which is like a global
$session->option( default => 1 ). So yeah, there will be output if
you're throwing events without destinations...
> > > Sep 27 17:12:40 devel qd[4687]: Event: trapped error in `??
> > Kernel.pm:698':
> > > Can't call method "due" without a package or object reference at
> > > QD/SQueue.pm line 178.
> > >
> > > OOOOOOOOOOOOOOOHHHHHHHHHHHHHHHH!!!!!!!!!!!!!!!!!!!!!!!!! A value had
> > > slipped in that was undefined, and I didn't check for it, because I didn't
> > > get a warning.
> >
> > That's strange. Why wouldn't you get a warning without Event? The
> > error is there either way...
>
> Confirmed. This warning does *NOT* appear unless the Event module is
> loaded. Additionally, Event makes it a simple warning, whereas w/ POE it's
> a silent exit on the session (which kills my program).
>
> > > Should this be a listed debugging suggestion/technique?
> >
> > As a short-term suggestion, yeah. A better long-term plan would be to
> > find out why the error didn't show up and fix things so it will. As
> > far as I can tell, POE doesn't trap errors of any kind, and it still
> > puzzles me that you wouldn't normally see the error message.
>
> Well, the data structure I was in looked like this:
>
> (not the session object, one of my data structures)
> $object->do_something_with($item);
>
> sub do_something_with {
> my $self = shift;
> my $account = shift;
>
> $self->delta($account->due);
> }
>
> If $item is undef, we get the above error, with the differences listed above
> between "with Event" and "without Event".
>
> If this is a "POE should CATCH this!", then UR welcome! :-)
Thank you! It's more like "POE should not hide your errors" but I
still don't know why that would happen. Time to write some test cases
and see if I can reproduce the problem.
> Otherwise, I suggest a bug/traps/warnings/caveat in the docs.
>
> Actually, while we're on the subject,
> before this instance,
>
> why, and in what situations, would you recommend using the Event module? I
> can understand the situations regarding the Tk/Gtk event loops.
There are only a few cases I can think of:
1. If Event ever becomes perl 5's standard event loop, you may want
your programs to use it.
2. Your POE-based program needs to use some other module that requires
Event.
3. Your program needs to handle a lot of signals, but you don't want
to use bleadperl. Event polls for signals in C, and it's supposed to
be safer than perl's regular handlers.
-- Rocco Caputo / [EMAIL PROTECTED] / poe.perl.org / poe.sourceforge.net
