FAQ
Hi,

I upgraded to Catalyst::Plugin::StackTrace 0.05 earlier tonight and
ran into a slight problem with a TT template I was working on.

The template uses Template::Plugin::File to display an (optional) set
of images; as mentioned in its documentation, it throws a
Template::Exception when the file does not exist. In the template:

[% TRY %]
[% USE File(c.path_to('root', 'static', 'images', 'nonexistent.jpg')) %]
<img src="[% c.uri_for('/static/images/nonexistent.jpg') %]" />
[% CATCH %]
No image...
[% END %]

Using Catalyst::Plugin::StackTrace 0.04 this would display "No
image...". With 0.05 this displays the img tag.

--
Daniel Westermann-Clark

Search Discussions

  • Justin Guenther at Jul 17, 2006 at 5:48 am

    -----Original Message-----
    From: catalyst-bounces at lists.rawmode.org
    [mailto:catalyst-bounces at lists.rawmode.org] On Behalf Of
    Daniel Westermann-Clark
    Sent: July 15, 2006 9:58 PM
    To: catalyst at lists.rawmode.org
    Subject: [Catalyst] C::P::StackTrace eats template exceptions?

    Hi,

    I upgraded to Catalyst::Plugin::StackTrace 0.05 earlier
    tonight and ran into a slight problem with a TT template I
    was working on.

    The template uses Template::Plugin::File to display an
    (optional) set of images; as mentioned in its documentation,
    it throws a Template::Exception when the file does not exist.
    In the template:

    [% TRY %]
    [% USE File(c.path_to('root', 'static', 'images',
    'nonexistent.jpg')) %]
    <img src="[% c.uri_for('/static/images/nonexistent.jpg')
    %]" /> [% CATCH %]
    No image...
    [% END %]

    Using Catalyst::Plugin::StackTrace 0.04 this would display
    "No image...". With 0.05 this displays the img tag.
    Thanks, I'll take a look at this tomorrow

    --
    Daniel Westermann-Clark

    _______________________________________________
    List: Catalyst at lists.rawmode.org
    Listinfo: http://lists.rawmode.org/mailman/listinfo/catalyst
    Searchable archive:
    http://www.mail-archive.com/catalyst at lists.rawmode.org/
    Dev site: http://dev.catalyst.perl.org/
  • Justin Guenther at Jul 22, 2006 at 1:12 am
    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!
  • Christopher H. Laco at Jul 22, 2006 at 1:32 am

    Justin Guenther wrote:
    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!
    I think I have a side-case for this. I'm running StackTrace 0.05 and
    working on a Model which uses Handel. The very minute I load handel (use
    Handel::Cart), and exceptions it throws (via Error) are displayed on the
    first request in the debug screen.

    The 2nd+ requests to the same page, method, throwing the same exception,
    the error appears in the top message/error debug box, but the entire
    stack trace output is missing.

    I suspect this is the same issue, my use of Error, and it's DIE handlers
    in there.

    Not loading Handel, or not loading Error within, relieves the problem.

    For the curious, the model is not more than:
    package Catalyst::Model::Handel::Cart;
    use strict;
    use warnings;
    use Scalar::Util qw/blessed/;
    use Class::Inspector;
    use Catalyst::Exception;
    use base qw/Catalyst::Model Class::Accessor::Grouped/;

    __PACKAGE__->mk_group_accessors('inherited', qw/cart_class connection_info/);

    sub COMPONENT {
    my $self = shift->SUPER::new(@_);
    my $cart_class = $self->cart_class || 'Handel::Cart';
    if (!Class::Inspector->loaded($cart_class)) {
    eval "use $cart_class";
    if ($@) {
    die "Could not load cart class $cart_class: $@";
    } else {
    $self->cart_class($cart_class);
    };
    };
    $self->cart_class->storage->connection_info($self->connection_info);

    return $self;
    };

    sub new {
    return shift->cart_class->new(@_);
    };

    1;
    -------------- next part --------------
    A non-text attachment was scrubbed...
    Name: signature.asc
    Type: application/pgp-signature
    Size: 189 bytes
    Desc: OpenPGP digital signature
    Url : http://lists.rawmode.org/pipermail/catalyst/attachments/20060721/2869b7d1/attachment.pgp
  • Aristotle Pagaltzis at Jul 22, 2006 at 1:47 am

    * Justin Guenther [2006-07-22 03:20]:
    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 have no idea if this is the problem or not, but there was a
    discussion about rethrowing just a few days ago on PerlMonks
    which mentioned similar issues:

    Rethrowing with die $@ considered harmful
    http://www.perlmonks.org/index.pl?node_idV1895

    I don?t know if that?ll be any help, but who knows.

    Regards,
    --
    #Aristotle
    *AUTOLOAD=*_;sub _{s/(.*)::(.*)/print$2,(",$\/"," ")[defined wantarray]/e;$1};
    &Just->another->Perl->hacker;

Related Discussions

Discussion Navigation
viewthread | post
Discussion Overview
groupcatalyst @
categoriescatalyst, perl
postedJul 16, '06 at 3:58a
activeJul 22, '06 at 1:47a
posts5
users4
websitecatalystframework.org
irc#catalyst

People

Translate

site design / logo © 2022 Grokbase