我正在清理一些代码,但我不确定哪条路线更好。
目前,我的大部分方法都有一个 try catch 块,它在最后处理一些单独的异常,但我认为有更多的 try catch 块对于维护来说会更好。然而,在分解代码时,我发现我正在为同一类型的异常编写多个块。我可以看到为每个部分编写一个块的好处,因为然后我可以给出更多细节来说明它失败的原因。
我的问题是……这样做有什么缺点吗?是否存在性能问题或其他我没有看到的隐藏问题?
另外,在一个方法中处理多个异常的首选方式是什么,是否有行业标准?
为了更好地说明我的观点,这里有一些伪代码
//multiple try catch for same exception
try {
//some code here
} catch (MyException e) {
//specific error message here
}
try {
//some different code here
} catch (MyException e) {
//more specific error message indicating a different issue
}
我总是尝试减少嵌套级别以提高可读性和可维护性。如果你有 n 个 try/catch 块,每个块都处理相同类型的异常,为什么不重构可以将异常抛出到方法中的代码......它看起来像:
try {
firstBatchOfTricky();
secondBatchOfTricky();
....
nthBatchOfTricky();
} catch (ItWentBoomException e) {
// recover from boom
} catch (ItWentBangException e) {
// recover from bang
}
这比多个 try/catch 更具可读性。请注意,您的方法应该本着自记录代码的精神来描述它们的功能。
由于您有自己的异常类型,因此您可以将所需的数据添加到异常中,以便在 catch 块中执行不同的操作。当你说“更具体的消息”时,你可以直接抛出带有详细消息的异常;你不应该需要多个 catch 块。如果你想根据异常的状态做完全不同的事情,只需创建更多的异常类型和 catch 块,但只有一个 try 块,如我的伪代码所示......
最后,如果无法从异常中恢复,则不应使用 catch 块使代码变得混乱。抛出运行时异常并让它冒泡。 (评论中来自@tony的好建议)
本文内容由网友自发贡献,版权归原作者所有,本站不承担相应法律责任。如您发现有涉嫌抄袭侵权的内容,请联系:hwhale#tublm.com(使用前将#替换为@)