[Catalyst] C::P::StackTrace eats template exceptions?

Justin Guenther jguenther at gmail.com
Sat Jul 22 03:12:35 CEST 2006


Just so nobody thinks this is getting ignored, I'm working on fixing it but
the problem runs deeper than it would initially appear. C::P::StackTrace
does its magic by having a localized $SIG{__DIE__} in the extended execute()
method. It collects a Devel::StackTrace object and saves it for use in the
finalize_error phase, which renders the error and makes it look pretty.

The problem is that with overriding $SIG{__DIE__}, _any_ exception,
including ones caught by an eval{} block, are caught by the signal handler.
This can be avoided by having `local $SIG{__DIE__}' and `local $@' in scope
with the eval, but this is a messy workaround. (this is how the ACL plugin
fixed the issue)

In this particular case, Template::Toolkit uses exception objects, which
seem to get completely eaten somewhere between getting thrown and caught by
eval{}. The $@ variable is the empty string, in this case, and it's
completely impossible to tell if there is an exception or not.

I'm still working on this, but if anyone wants to check out the code in the
C::P::StackTrace repository and step the perl debugger through the failing
testcase I committed, it'd be a big help to get some more sets of eyes on
this. If you can figure out where and why the $@ variable is being set to ''
on object exceptions, you get a cookie!




More information about the Catalyst mailing list