1

考虑以下操作：

sub get_stuff :Chained('/') :PathPart('stuff') :CaptureArgs(1) {
  my ($self,$c,$stuff_id) = @_;
  die "ARRRRRRGGGG";
}

sub view_stuff :Chained('get_stuff') :PathPart('') :Args(0){
  die "DO'H";
}

现在如果你请求 '/stuff/314/' ，你会得到

Error: ARRRRG in get_stuff at ...

Error: DO'H in view_stuff at ...

有没有理由不直接在第一个失败的链环上抛出错误？

为什么催化剂要上链？

4

4 回答 4

2

我不确定“为什么”的答案，但我认为这样做是为了提供灵活性。

您可能应该使用 eval （或者最好是Try::Tiny或TryCatch$c->detach之类的东西）捕获错误，如果您想停止处理操作，请调用。

于 2011-03-02T16:27:43.050 回答
1

Catalyst::Plugin::MortalForward

于 2011-10-05T18:32:15.537 回答
1

选择的答案可能已过时。abort_chain_on_error_fix当应用程序的配置键被设置时，催化剂可能会提前死掉。

__PACKAGE__->config(abort_chain_on_error_fix => 1);

请参阅有关Catalyst 配置的文档。它还指出，这种行为将来可能是标准的。

于 2014-04-08T11:49:59.490 回答
0

葫芦是对的，分离是要走的路。至于为什么，通常在 perl 进程中，“死”会停止该进程。在 Catalyst 中，您不希望这样。例如，如果您在 FastCGI 下运行 Catalyst 应用程序，则会生成一个或多个处理多个请求的独立进程。如果第一个请求会杀死进程本身，那么 Web 服务器将不得不重新启动 FastCGI 进程才能处理下一个调用。我认为为此，Catalyst 会捕获“die”（它经常用作默认的“do_something() 或 die $!”）并将其转换为异常。

我猜你也可以用'exit'结束进程，但你最终会遇到与上面相同的问题，终止进程。您当然可以做的是创建自己的“die”方法，该方法记录使用默认日志对象传递的错误，然后调用 detach 或其他方法。还应该可以重新定义 Catalyst 异常处理，因为 Catalyst 一切皆有可能:)

于 2011-03-20T12:01:53.713 回答