[Catalyst] Error handling strategy wrt /end

[apv]

I'm still refactoring but this is what I'm doing right now (improvement 
ideas?):

MyApp:

sub end : Private {
     my ( $self, $c ) = @_;
     return 1 if $c->response->body;
     return 1 if $c->response->status =~ /^3\d\d$/;
     # render, but maybe template itself is the problem
     $c->forward( $c->view('TT') );

     # false means another error, so we have to rerender
     $c->forward(qw( Controller::Errors error_to_template ))
         or $c->forward( $c->view('TT') );

     $c->request->parameters->{password} = undef;
     $c->fillform()
         if $c->request->method() eq 'POST';
}

MyApp::Controller::Errors looks, in part, like so:

my @Error_Map = # order counts
     (
      qr/\b(?:DBI|MyApp::Model::)\b/ => {
          status => "503",
          title => "503: service unavailable",
          template => "page/generic_error",
          message  => 1,
          notify => 1,
      },
...

sub error_to_template : Private {
     my ( $self, $c ) = @_;
     return 1 unless @{ $c->error };

     my $err_str = join " ", @{$c->error};

     for ( my $i = 0; $i < @Error_Map; $i += 2 )
     {
         my ( $rx, $config ) = @Error_Map[$i,$i+1];

         next unless $err_str =~ /$rx/;

         if ( $1 ) {
             $config->{status} ||= $1;
             $config->{title}  ||= "$1: " . status_message($1);
         }

         $config->{message} = $c->error
             if $config->{message} or $c->debug;

         my $iter = $i == 0 ? 0 : ($i / 2);
         $iter++;
         push @{$config->{message}}, "Caught in error iteration $iter";

         $c->stash( %{ $config } );

         $c->response->status( $config->{status} );
         $c->error(0);
         return 0;
     }
#        $c->forward(qw( Controller::Utilities mail_error ))
#            if $c->config->{mail_error} and $config->{notify};
}

-Ashley

On Thursday, January 26, 2006, at 02:43  PM, Phil Mitchell wrote:

> My actions all have an eval block that lets me catch and handle 
> exceptions thrown by my model classes. What this leaves out is any 
> exceptions that arise once the work is handed off to the TT view -- in 
> /end. What this means is that for most errors, I provide a nice error 
> message; but if TT dies, the user gets the generic catalyst error 
> screen. Not nice.
>
> I could catch these exceptions by explicitly forwarding to /end inside 
> each eval cage, but that kind of defeats the point of having the /end 
> action. Also, I don't want to use TT try/catch blocks, bc I want the 
> error handling all in one place.
>
> Curious to know how other people approach error handling.
>

>
>
> --
> ==========================
> 2People Blog: http://2-people.blogspot.com/
> 2People site: http://www.2people.org 
> _______________________________________________
> Catalyst mailing list
> Catalyst at lists.rawmode.org
> http://lists.rawmode.org/mailman/listinfo/catalyst