我有一个类XYZ
,其公共函数抛出Exception
s。
我被告知XYZ
公开的所有公共函数都应抛出名为XYZDataException
或XYZSystemException
的异常。因此,即使我在公共方法中得到其他异常,也需要将它们包含在这些XYZException
中。
我有几个问题:
对我而言,只是抛出任何异常而不进一步包装它是正确的。
答案 0 :(得分:4)
许多异常处理取决于您以后计划如何扩展它。例如,如果开发人员B出现并希望修改一些代码,那么如果他了解Exception在哪种情况下意味着什么,那将会容易得多。在这种情况下,具有特定的异常更有意义。
至于分解系统和数据异常 - 数据异常基本上应该是由于数据不良而发生的非致命异常。系统异常是因为您的系统以某种方式失败。同样,这一切都指向了以后如何使用它。如果您只想单独使用代码,并且不关心异常如何回归,那么请务必使用当时最简单的代码。
我发现在与项目上的其他开发人员合作时,他们可以更轻松地掌握您的异常子类并在特定情况下抛出它们时发生的事情。
希望这有帮助!
答案 1 :(得分:2)
是的,这意味着它们可以被知道如何处理它们的代码明确捕获。
例如,假设你有:class MyRecoverableException extends Exception {
...
}
然后,您可以拥有可以自动区分它们的代码,并做出相应的反应,例如:
try{
// ... do something ...
}catch(MyRecoverableException e) {
// Recover
}catch(Throwable t) {
// Log fatal reason, and exit gracefully.
}
显然你需要多少是一个问题需要你,应用程序开发人员解决,但是一个干净的分离可以解决出错的问题,而子类异常可以包含其他属性,用于传递相关信息处理他们带来的特殊情况。
从你的应用程序/库扩展的基类型永远不会受到伤害 - 如果没有其它原因而不是在记录时允许分离源 - 但除此之外所需的确切层次结构和复杂性完全取决于项目。有些设计有自然而明显的选择,有些需要更多的预见(偶尔会有一些事后的想法和重构)。
答案 2 :(得分:1)
优点是处理这些异常的更高级别不会暴露于生成这些异常的实现细节。此外,也许在较小的程度上,异常可能更有意义地分组(它是否与IOException相关,或者是否足以知道写入您正在使用的任何输出存储时存在问题)。
另一个很大的优势是可以在自定义例外中捕获特定于应用程序的信息。用户ID,帐号等等 - 任何应用程序状态 - 必须作为字符串消息的一部分存储在“库存”异常中,可以分配给属性。如果您实际执行任何异常或尝试跟踪特定事件流,这可能会避免随机解析问题。
答案 3 :(得分:1)
根据msdn:
要包装异常,请将其指定为新异常的内部异常,然后抛出新异常。这种做法只应在接收异常的原始异常无意义的情况下使用,或者异常的调用堆栈具有误导性或无趣性。
答案 4 :(得分:0)
假设方法M1被记录为在某些条件发生时抛出类型X的异常。 M1调用方法M2,这恰好抛出了M1未准备处理的类型X的异常。如果M1没有捕获到M2的异常,则调用者不太可能发现M1抛出的异常不是M1抛出的X,而是M2抛出的X,其实际意义和含义可能非常不同。让M1抛出一个永远不会被M2抛出的类型的例外可以避免这个问题(尽管如果M2可以在某个其他对象上调用M1,仍然会有麻烦)。