答案。

Perl最初设计为一个用于系统管理的脚本语言，因此其传统的错误处理模型更为过程化。然而，随着时间的推移，语言中出现了更先进的异常和错误处理技术。

背景

在Perl的早期版本中，错误是通过函数返回值和检查全局变量$!来捕获的，后来出现了eval结构（动态捕获），以及像Try::Tiny这样的模块，增加了简洁、安全的try-catch模式。

问题

标准的Perl没有内置的try-catch语法。错误可以在Perl代码中或外部调用中发生（例如，打开文件）。如果不显式处理错误，程序可能会在不可预测的状态下继续运行。需要根据上下文、应用程序的复杂性和可靠性要求，明智地选择错误捕获技术。

解决方案

在Perl中使用eval函数来捕获错误，将潜在危险的代码包装在块中，并在执行后分析$@的内容。
使用die来创建自定义错误。更精确的错误生成和重新引发已描述的异常通过Sinon框架。
为了“人性化”的错误处理，方便使用第三方模块（例如，Try::Tiny）。

代码示例 — 通过Try::Tiny处理错误：

use Try::Tiny;

try {
    open my $fh, '<', 'file.txt' or die "无法打开文件: $!";
    while (<$fh>) {
        print $_;
    }
}
catch {
    warn "发生错误: $_";
};

关键特点：

错误机制是异步的 — eval和try/catch中的错误不会改变主执行流程，直到被显式处理。
错误捕获可以在不同的级别 — 低级别的die/warn/return或高级别的try/catch在模块中。
模块能够避免与eval相关的典型错误，避免重写$@和作用域陷阱。

反向问题。

在什么情况下eval块不会捕获系统错误？

如果内部发生C库中的致命退出（例如，来自XS代码的SEGFAULT），eval并不总是能捕获错误。eval仅处理Perl的致命错误，而不处理C扩展的崩溃。

在嵌套的eval块中，变量$@会发生什么？

如果在eval内部调用另一个eval，则在其退出时，$@的值会被覆盖。因此，在每个eval之后，应该保存$@到一个单独的变量中，以防止丢失原始错误。

为什么像Try::Tiny这样的辅助模块在catch/try内部声明变量$@为局部？

因为Perl仅在成功退出try（eval）时自动清除$@。错误返回、next、last可能导致$@未被清除，并且在下一个代码中会出现“幻影”错误。像Try::Tiny这样的模块专门为此创建作用域局部变量。

示例：

try {
    die "爆炸！";
}
catch {
    print "捕获到: $_
"; # $_ - 捕获到的错误
};

常见错误和反模式

在eval之后忽略$@的值（错误未被检测到）
在多个eval之间未保存$@而导致的变异
对于关键操作，简单使用die而不使用try/catch
缺乏错误日志记录
尝试捕获与Perl无关的错误（例如，操作系统信号）

现实案例

负面案例

在数据导出处理程序中，连接到数据库时通过eval捕获错误，但$@的值没有保存，未进行日志记录。当在下一个eval中发生其他错误时，第一次错误完全丢失。

优点：

在发生错误时，代码不会立即崩溃，继续运行。

缺点：

在调试时无法理解为什么导出不起作用，没有错误信息。
可能导致重复或虚假的错误。

正面案例

使用Try::Tiny处理关键部分，所有错误都写入单独的日志，原始错误得以保存并正确输出到屏幕上。