Question

我很难找到一种方法来处理基于Catalyst::Controller::REST的API中的意外错误。

BEGIN { extends 'Catalyst::Controller::REST' }

__PACKAGE__->config(
    json_options => { relaxed => 1, allow_nonref => 1 },
    default      => 'application/json',
    map          => { 'application/json' => [qw(View JSON)] },
);

sub default : Path : ActionClass('REST') { }

sub default_GET {
    my ( $self, $c, $mid ) = @_;

   ### something happens here and it dies
}

如果default_GET意外死亡，则会显示应用程序标准状态500错误页面。我希望控制器后面的REST库能够控制它并显示JSON错误（或者REST请求接受的任何序列化响应）。

通过操作添加错误控制（使用ie Try::Tiny）操作不是一种选择。我希望集中所有错误处理。我尝试使用sub end操作，但这不起作用。

sub error :Private {
    my ( $self, $c, $code, $reason ) = @_;

    $reason ||= 'Unknown Error';
    $code ||= 500;

    $c->res->status($code);

    $c->stash->{data} = { error => $reason };
}

Answer 1

这不是最佳做法。这就是我如何做到的。

您可以使用Try::Tiny来捕获控制器中的错误，以及Catalyst :: Action :: REST带来的帮助程序，以发送相应的响应代码。它将负责将响应转换为正确的格式（即JSON）。

但是仍然需要你为每种类型的错误做这件事。基本上它归结为：

use Try::Tiny;
BEGIN { extends 'Catalyst::Controller::REST' }

__PACKAGE__->config(
    json_options => { relaxed => 1, allow_nonref => 1 },
    default      => 'application/json',
    map          => { 'application/json' => [qw(View JSON)] },
);

sub default : Path : ActionClass('REST') { }

sub default_GET {
    my ( $self, $c, $mid ) = @_;

    try {
        # ... (there might be a $c->detach in here)
    } catch {
        # this is thrown by $c->detach(), so don't 400 in this case
        return if $_->$_isa('Catalyst::Exception::Detach');

        $self->status_bad_request( $c, message => q{Boom!} );
    }
}

Catalyst::Controller::REST under STATUS HELPERS列出了这些响应的方法。他们是：

您可以通过继承Catalyst :: Controller :: REST或添加到其命名空间中来为缺失状态¹实现自己的状态。 Refer to one of them了解它们的构造方式。这是一个例子。

*Catalyst::Controller::REST::status_teapot = sub {
    my $self = shift;
    my $c    = shift;
    my %p    = Params::Validate::validate( @_, { message => { type => SCALAR }, }, );

    $c->response->status(418);
    $c->log->debug( "Status I'm A Teapot: " . $p{'message'} ) if $c->debug;
    $self->_set_entity( $c, { error => $p{'message'} } );
    return 1;
}

如果因为你有很多动作而太繁琐，我建议你按照你的意图使用end动作。更多关于如何在下面进一步工作。

在这种情况下，请不要将Try :: Tiny构造添加到您的操作中。相反，请确保您使用的所有模型或其他模块都有很好的例外。为每个案例创建异常类，并将对应该发生的事情的控制交给他们。

完成所有这些操作的好方法是使用Catalyst::ControllerRole::CatchErrors。它允许您定义将为您处理错误的catch_error方法。在该方法中，您构建一个分派表，该表知道哪个异常应该导致哪种响应。另请查看documentation of $c->error，因为它在此处提供了一些有价值的信息。

package MyApp::Controller::Root;
use Moose;
use Safe::Isa;

BEGIN { extends 'Catalyst::Controller::REST' }
with 'Catalyst::ControllerRole::CatchErrors';

__PACKAGE__->config(
    json_options => { relaxed => 1, allow_nonref => 1 },
    default      => 'application/json',
    map          => { 'application/json' => [qw(View JSON)] },
);

sub default : Path : ActionClass('REST') { }

sub default_GET {
    my ( $self, $c, $mid ) = @_;

    $c->model('Foo')->frobnicate;
}

sub catch_errors : Private {
    my ($self, $c, @errors) = @_;

    # Build a callback for each of the exceptions.
    # This might go as an attribute on $c in MyApp::Catalyst as well.
    my %dispatch = (
        'MyApp::Exception::BadRequest' => sub { 
            $c->status_bad_request(message => $_[0]->message); 
         },
        'MyApp::Exception::Teapot' => sub {
            $c->status_teapot; 
         },
    );

    # @errors is like $c->error
    my $e = shift @errors;

    # this might be a bit more elaborate
    if (ref $e =~ /^MyAPP::Exception/) {
        $dispatch{ref $e}->($e) if exists $dispatch{ref $e};
        $c->detach;
    }

    # if not, rethrow or re-die (simplified)
    die $e;
}

以上是粗略的未经测试的示例。它可能不会完全像这样，但它是一个良好的开端。将调度移动到主Catalyst应用程序对象的属性（上下文$c）是有意义的。将它放在MyApp :: Catalyst中即可。

package MyApp::Catalyst;
# ...

has error_dispatch_table => (
    is => 'ro',
    isa => 'HashRef',
    traits => 'Hash',
    handles => {
        can_dispatch_error => 'exists',
        dispatch_error => 'get',
    },
    builder => '_build_error_dispatch_table',
);

sub _build_error_dispatch_table {
    return {
        'MyApp::Exception::BadRequest' => sub { 
            $c->status_bad_request(message => $_[0]->message); 
         },
        'MyApp::Exception::Teapot' => sub { 
            $c->status_teapot; 
         },
    };
}

然后按照以下方式进行调度：

$c->dispatch_error(ref $e)->($e) if $c->can_dispatch_error(ref $e);

现在你需要的只是好的例外。有不同的方法来做到这些。我喜欢Exception::Class或Throwable::Factory。

package MyApp::Model::Foo;
use Moose;
BEGIN { extends 'Catalyst::Model' };

# this would go in its own file for reusability
use Exception::Class (
    'MyApp::Exception::Base',
    'MyApp::Exception::BadRequest' => {
        isa => 'MyApp::Exception::Base',
        description => 'This is a 400',
        fields => [ 'message' ],
    },
    'MyApp::Exception::Teapot' => {
        isa => 'MyApp::Exception::Base',
        description => 'I do not like coffee',
    },
);

sub frobnicate {
    my ($self) = @_;

    MyApp::Exception::Teapot->throw;
}

同样，将异常移到他们自己的模块中是有意义的，这样你就可以在任何地方重复使用它们。

我相信这可以很好地延长。还要记住，将业务逻辑或模型与业务逻辑或模型耦合得太强，以至于它是一个Web应用程序是一个糟糕的设计。我选择了非常简单的异常名称，因为这很容易解释。您可能想要更通用或更少的以网络为中心的名称，并且您的调度应该采用实际映射它们。否则它与网络层的关联太多了。

^{1）是的，这是复数。见here。}

使用Catalyst :: Controller :: REST

1 个答案: