软件随想录(local.joelonsoftware.com/wiki)-2003年10月13日 异常处理 - Exceptions

2003年10月13日 异常处理 - Exceptions

 

 

异常处理

From The Joel on Software Translation Project

异常处理

有人问我为什么不喜欢写含有异常处理的程序。无论在 Java 或 C++ 里,我的原则都是:

  1. 绝不主动丢出异常状况。
  2. 总是在用到某函式库那行就逮住可能由它掷出的任何异常状况,并立刻解决。

理由是我不认为异常处理比 "goto" 好。"goto" 自 1960 年代以来便被视为是有害的,因为它从程序代码某处鲁莽地跳到另一处。事实上异常处理和 goto 比起来有更重大的缺陷:

  1. 异常处理在源代码中是隐形的。检阅一段程序,无论函式会不会抛出异常状况,都没办法看出异常状况可能是什么或发生在那里。这表示即使小心核对程序代码也纠不出潜在的 bug。
  2. 异常处理在函式里产生了太多出口。想写好程序,你得想清楚函式里每个可能的步骤。每次你呼叫某个可能引发异常状况的函式又没能当机立断,你就替意料之外的 bug 制造了硬生生地终结函式的机会,而使资料陷于不一致的状态下或跑到你没想到的程序里。

比较可取的方法是在函式出问题时回报错误,那怕它会有些冗赘,也要明确地处理。的确,当你在程序里加入良好的错误检验时,原来简短三行的程序常会膨胀到 48 行,但人生不如意事十之八九,况且用异常处理粉饰程序并不会让它更强韧。我想 C/C++/Java 式语言的程序设计师会被异常处理吸引的理由,只是单纯地因为文法规则里没有简洁的方式能叫用传回多重数值的函式,所以产生回传值或回报错误的函式写起来不容易。(ML 和 Haskell 是我常用的程序语言里少数能巧妙地传回多值的语言。)在 C/C++/Java 式语言里有一招可以用来处理错误,就是以实际回传数值代表结果的状态,同时如果有想要传回的东西,就传入 OUT 参数来存取。这样的作法有个令人遗憾的副作用是无法层层呼叫函式,于是 f(g(x)) 的答案得改成:

T tmp;
if (ERROR == g(x, tmp))
    errorhandling;
if (ERROR == f(tmp, result))
    errorhandling;

这样又丑又麻烦,但比无法预期的部分带著诡异的 goto 夹杂在程序代码里好多了。

 

评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值