为何使用try/catch/finally处理异常？参数校验能否替代异常捕获？

你的这个问题戳中了很多开发者刚接触异常处理时的困惑——既然能提前把漏洞补上，为啥还要搞try/catch这一套？其实参数校验和异常处理根本不是二选一的对立关系，而是互相配合的搭档，下面结合你举的除法例子给你掰明白：

1. 参数校验是「事前堵漏洞」，但没法顾全所有情况 #

就像你说的，用@NotNull、isDigit()这类校验，能提前拦住b是null、字符的情况，这肯定是最优解——把问题掐在执行前，省得后面触发异常折腾。

但问题是：你能预判所有可能出岔子的地方吗？
比如除法场景里，除了b为0、null、字符，还可能碰到：

• a和b是数组但维度不匹配，MATLAB执行除法直接报错；
• 你调用的某个底层函数突然因为依赖更新抛出了新的异常；
• 并发场景下，你校验时b还是合法数值，刚校验完就被别的线程改成了0。

这些情况要么你想不到，要么没法靠参数校验完全拦住，这时候异常处理就派上用场了。

2. 异常处理是「事后擦屁股」，管的是你预判不到的风险 #

回到你的水桶例子：参数校验是提前检查水桶有没有裂缝，异常处理是漏水时赶紧把水接住、别弄湿地板。你能补上大部分可见的裂缝，但总有一些隐藏的、或者突然出现的漏水点——比如水桶突然被撞了个洞，这时候提前的检查没用，只能靠兜底的接水措施。

异常处理的核心作用就是应对不可预见、或者无法通过事前校验避免的错误，保证程序不会直接崩溃，而是能优雅地处理问题。

3. 多级catch不是花架子，是为了精细化处理不同问题 #

你提到的多级catch，不是用来替代参数校验的，而是为了针对不同类型的异常，做不同的补救动作：

• 比如抓到「除数为0」的异常，可以给用户弹个提示“请输入非0除数”，或者返回一个默认值；
• 抓到「参数类型不匹配」的异常，可以试着自动转换类型（比如把字符型的"5"转成数值5）；
• 最后那个兜底的catch，用来处理所有没见过的异常，比如记录日志、给个通用提示，避免程序直接挂掉。

4. 实际开发的正确姿势：先校验，再兜底 #

以你的除法函数为例，靠谱的写法应该是事前参数校验+事后异常兜底结合：

function c=div(a,b)
    % 事前拦截能预判的明显错误
    if isempty(b) || ~isnumeric(b)
        error('参数b必须是非空的数值类型');
    end
    if b == 0
        error('除数不能为0');
    end
    
    % 事后兜底处理未预见的异常
    try
        c = a / b;
    catch ME
        % 记录异常信息，方便排查问题
        disp(['执行除法时出现异常：', ME.message]);
        % 给出补救方案，比如返回默认值
        c = 0;
    end
end

这样既用参数校验减少了不必要的异常触发，又用异常处理覆盖了所有漏网之鱼，程序的健壮性才是真的拉满。

说白了，参数校验是主动防御，异常处理是被动兜底，两者结合才能搞定「能预见」和「不能预见」的所有风险——就像你既要提前检查水桶，也要备好接水的盆，这样才不会因为突发状况搞得一团糟。

内容的提问来源于stack exchange，提问作者bokabokaboka