这不是最佳做法。我就是这样做的。
您可以使用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 或添加到其命名空间来实现自己的缺失状态1。 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 应用程序这一事实过度耦合是不好的设计。我选择了非常有说服力的异常名称，因为这样很容易解释。您可能想要更通用或更不以网络为中心的名称，并且您的调度应该采取实际映射它们的方式。否则它与 web 层的联系太紧密了。
1) 是的，这是复数形式。见here。