java异常处理规范_java-异常处理标准建议

我认为电子邮件示例是检查异常的最佳防御方法.您可能会出错并且是暂时的,因此存在已检查的异常会让您考虑一下.如果一切都是运行时异常,则您的应用程序会因为一些琐碎的原因而崩溃,没人会考虑.

无论如何,如果对于您的项目,一般的答案是将其放在顶部,那么包装在运行时异常中是完全有效的.需要考虑的几件事：

坚持异常链接.不执行此操作的唯一原因是,如果您要序列化异常,那么对于某些包含不可序列化成员的异常,事情可能会变得很有趣.事实并非如此,因此请勿吞下异常.如果需要,请使用initCause.这是我们项目中的一些辅助方法：

public static T initCause(T newException, Throwable cause) {

return (T) newException.initCause(cause);

}

这可以帮助人们避免强制转换例外.

我更喜欢避免不必要的RuntimeException和Error Throwables链接,当方法上有许多不同的Checked Exceptions并且开发人员只是捕获E??xception时,不可避免地发生这种情况,因此我建议使用静态方法来执行以下操作：

public static void throwRuntimeExceptionFromThrowable(Throwable e) {

if (e == null) {

return;

} else if (e instanceof RuntimeException) {

throw (RuntimeException) e;

} else if (e instanceof Error) {

throw (Error) e;

} else {

throw new RuntimeException(e.getMessage(), e);

}

}

有两个选项.一种方法是使它无效(如该代码所做的那样),这使调用者永远不会忘记抛出结果.不利的一面是,如果您有这样的事情：

public Object someMethod() {

try {

return getTheObject();

} catch (Exception e) {

throwRuntimeExceptionFromThrowable(e);

}

}

编译器不会喜欢您.您必须在捕获之后返回,并在尝试之前声明一个变量.

另一个选择是将异常作为RuntimeException返回(仅抛出Error),并由调用方进行抛出.编译器更快乐,但是调用者可能会忘记这样做,并且在没有抛出任何方法的情况下调用该方法,然后吞没了异常.