为什么我不应该在“尝试”中包装每个块
我一直认为，如果一个方法可以抛出异常，那么不用保护有意义的尝试块来保护这个调用是鲁莽的。
我刚刚发布了'你应该总是打包可以尝试的电话，赶上块'。 对这个问题，被告知这是'非常糟糕的建议' - 我想明白为什么。
一个方法只有在能够以合理的方式处理它时才能捕获异常。
否则，传递它，希望调用堆栈中更高的方法可以理解它。
正如其他人所指出的那样，最好在调用堆栈的最高级别有一个未处理的异常处理程序（具有日志记录功能）以确保记录任何致命错误。
正如米奇和其他人所说的那样，你不应该找出你不打算以某种方式处理的例外。 您应该考虑应用程序在设计时如何系统地处理异常。 这通常会导致基于抽象的错误处理层 - 例如，处理数据访问代码中所有与SQL相关的错误，以便与域对象交互的应用程序部分不会暴露于是某个地方的引擎盖下的数据库。
除了“抓住所有地方”的气味外，还有一些相关的代码气味，你一定要避免。
“catch，log，rethrow”：如果你想基于范围的日志记录，那么编写一个类，当堆栈由于异常而展开时（ala std::uncaught_exception() ），它会在析构函数中发出日志语句。 你需要做的只是在你感兴趣的范围内声明一个日志记录实例，瞧，你有日志记录并且没有不必要的try / catch逻辑。
“catch，throw translation”：这通常指向抽象问题。 除非你正在实施一个联合解决方案，你将几个特定的异常转换成一个更通用的异常，否则你可能有一个不必要的抽象层，并且不要说“我明天可能需要它”。
“抓，清理，重新抛出”：这是我的宠物之一。 如果你看到很多这种情况，那么你应该应用资源获取是初始化技术，并将清理部分放置在Janitor对象实例的析构函数中。
我认为充斥着try / catch块的代码是代码审查和重构的好目标。 它表明，异常处理不是很好理解，或者代码已经成为amba，并且严重需要重构。
因为接下来的问题是“我发现了一个例外，接下来我该怎么办？” 你会怎么做？ 如果你什么都不做 - 那是隐藏的错误，程序可能“不起作用”，没有机会找到发生的事情。 你需要明白一旦你发现异常，你会做什么，只有当你知道时才会发现。
链接地址: http://www.djcxy.com/p/21125.html上一篇: Why should I not wrap every block in "try"
下一篇: Will code in a Finally statement fire if I return a value in a Try block?