我一直相信,如果一个方法可以抛出异常,那么不使用有意义的try块来保护这个调用就是鲁莽的。
我刚刚发布了‘你应该总是包装调用,可以抛出try, catch块。,结果被告知这是一个“非常糟糕的建议”——我想知道为什么。
我一直相信,如果一个方法可以抛出异常,那么不使用有意义的try块来保护这个调用就是鲁莽的。
我刚刚发布了‘你应该总是包装调用,可以抛出try, catch块。,结果被告知这是一个“非常糟糕的建议”——我想知道为什么。
当前回答
如果总是在可能抛出异常的方法的调用者中立即处理异常,那么异常就变得毫无用处,最好使用错误代码。
异常的全部意义在于,不需要在调用链中的每个方法中处理它们。
其他回答
我同意你的问题的基本方向,即在最低级别处理尽可能多的异常。
一些现有的回答是这样的:“您不需要处理异常。别人会在上面做的。”根据我的经验,这是一个不考虑当前开发的代码段异常处理的糟糕借口,让异常处理其他人或以后的问题。
在分布式开发中,这个问题会急剧增加,在分布式开发中,您可能需要调用由同事实现的方法。然后,您必须检查嵌套的方法调用链,以找出他/她为什么向您抛出一些异常,这在嵌套最深的方法中可以更容易地处理。
Herb Sutter在这里写过这个问题。绝对值得一读。 摘要:
"Writing exception-safe code is fundamentally about writing 'try' and 'catch' in the correct places." Discuss. Put bluntly, that statement reflects a fundamental misunderstanding of exception safety. Exceptions are just another form of error reporting, and we certainly know that writing error-safe code is not just about where to check return codes and handle error conditions. Actually, it turns out that exception safety is rarely about writing 'try' and 'catch' -- and the more rarely the better. Also, never forget that exception safety affects a piece of code's design; it is never just an afterthought that can be retrofitted with a few extra catch statements as if for seasoning.
如果您想测试每个函数的结果,请使用返回码。
exception的目的是为了降低测试结果的频率。其思想是将异常(不寻常的,罕见的)条件从更普通的代码中分离出来。这使得普通代码更简洁,但仍然能够处理那些异常情况。
在设计良好的代码中,较深的函数可能会抛出,较高级的函数可能会捕获。但关键是,许多“介于两者之间”的功能将完全摆脱处理异常情况的负担。它们只需要是“异常安全的”,这并不意味着它们必须捕获。
我听到过的最好的建议是,您应该只在可以对异常条件采取措施的情况下捕获异常,而“捕获、记录和释放”并不是一个好策略(如果在库中偶尔不可避免的话)。
因为下一个问题是“我已经捕获了一个异常,接下来我该做什么?”你会怎么做?如果你什么都不做——这是错误隐藏,程序可能“就是不能工作”,没有任何机会发现发生了什么。您需要了解捕获异常后要做什么,并且只有在知道的情况下才进行捕获。