2012-02-21 15 views
1

我有一个类XYZ其公共函数抛出Exception s。在Java中使用自定义异常类型包装异常是否有优势

我被告知所有公开职能由XYZ公开应该抛出异常,称为XYZDataExceptionXYZSystemException。因此,即使我在公共方法中遇到其他例外情况,也需要用这些XYZException s来包装。

我有几个问题:

  1. 什么是XYZException包装异常的优势在哪里?
  2. 区分系统和数据异常的优点是什么?

对我来说,只要抛出任何异常而没有进一步包装它,这种感觉是正确的。

回答

4

很多异常处理取决于您计划如何扩展它。例如,如果开发者B出现并想要修改一些代码,那么如果他明白Exception是什么意思,那将会容易得多。在这种情况下,具有特定的例外情况会更有意义。

至于分手系统和数据异常 - 一个数据异常基本上应该是非因数据不良而发生的非致命事件。系统异常将是因为您的系统以某种方式失败。再一次,这一切都指向你以后如何使用它。如果你只想单独使用你的代码,并且你不关心你的异常是如何返回的,那么通过一切手段,使用当时最简单的方法。

我发现,在与项目中的其他开发人员一起工作时,他们很容易掌握当您将异常子类化并抛出特定情况时发生了什么。

希望这会有所帮助!

2

是的,这意味着它们可以被知道如何处理它们的代码明确捕获。

例如,假设你有:

class MyRecoverableException extends Exception { 
    ... 
} 

然后,您可以有代码,可以自动区分它们,并做出相应的反应,如:

try{ 
// ... do something ... 
}catch(MyRecoverableException e) { 
    // Recover 
}catch(Throwable t) { 
    // Log fatal reason, and exit gracefully. 
} 

显然,你需要多少是应用程序开发人员需要解决的一个问题,但清理分离可以在计算出什么地方出错时起到重要作用,并且子类别异常可以包含其他属性,用于向处理程序传递有关异常情况的相关信息带给他们的东西。

让您的应用程序/库具有扩展的基本类型从不会伤害任何其他原因 - 如果没有其他原因而允许在日志记录时允许源分离 - 但除此之外所需的确切层次结构和复杂性完全取决于项目。有些设计有自然而明显的选择,有些需要更多的预先考虑(偶尔会有一些事后考虑和重构)。

1

像往常一样,“这取决于”。作为一般规则,而不是是有意义的,以每个班级为基础盲目创建一个例外层次结构。特定于应用程序的异常应该以对特定应用程序有意义的方式对异常进行分组,因此可能会出现顶级异常,然后对数据层,通信层,实用程序等其他类进行分类。

优点是处理这些异常的更高级别不会暴露给生成这些异常的实现细节。此外,也许对出租人程度来说,异常可能会更有意义地分组(这是相关的,它是一个IOException,或者足以知道写入到您正在使用的任何输出存储中有问题)。

另一个很大的优势是可以在自定义例外中捕获特定于应用程序的信息。诸如用户ID,帐号等等 - 任何应用程序状态 - 必须作为字符串消息的一部分存储在“股票”异常中可以被分配给属性。这可能会避免随机解析问题,如果您实际上做了例外情况或试图通过特定事件流进行跟踪。

1

根据msdn

要包装一个例外,可以指定它作为一个新的异常的内部异常,然后抛出新的异常。只有在接收到异常的人员的原始例外无意义或者异常的调用堆栈具有误导性或无趣时,才应使用此方法。

0

假设方法M1记录为当某些条件发生投掷X类型的异常。 M1调用方法M2,恰好引发了M1不准备处理的类型X的异常。如果M1没有捕捉到M2的异常,调用者不太可能知道M1抛出的异常不是M1抛出的X,而是M2抛出的X,它的实际含义和含义可能是非常不同的。让M1抛出M2永远不会抛出的类型的异常可能会避免这个问题(尽管如果M2可以在某个其他对象上调用M1的话,仍然会有麻烦)。