是"抛出可扔"的好习惯

Fra*_*ner 29 java

在过去,我会用以下方法阅读大量代码:

public Object doSomething() throws Throwable {
    ...
}
Run Code Online (Sandbox Code Playgroud)

通常的做法是这样做吗?

什么是利弊?

throws Trowable 在我看来,像"特工橙"的方式让异常完成了

编辑


  1. 处理方法中的预期异常

  2. 抛出意外的异常(逐个)

  3. 不关心错误

这是要走的路吗?

Boh*_*ian 46

你不应该扔Throwable.这就是原因.

Throwable是可抛出的事物层次结构的顶层,由Exceptions和组成Errors.由于Errors定义来自不可挽回的条件,因此将它们包含在方法声明中是没有意义的.那就离开了Exception.

你应该用声明你的方法throws Exception.


请注意,范围越窄throws越好.

throws Exception如果您的方法不生成异常,则声明您的方法是正确的,而是调用声明为的其他代码,throws Exception并且您希望异常渗透调用堆栈.

如果您的方法是生成异常,则声明更窄的范围,例如throws IOException, MyProcessingException,等等

  • 我想补充一点,如果您正在渗透的异常可以通过链上的某个点上的代码来纠正,那么可以声明抛出Exception(),但是如果它不是代码用来修复自身的东西,那么你应该捕获异常并将它们重新抛出为RuntimeExceptions.在这种情况下,您不会在您的方法上声明它会抛出运行时异常,而是使用javadoc来记录它. (2认同)

mpr*_*vat 9

这是一个有问题的问题.这与异常处理无关,因为它与代码可读性有关.

这取决于您从哪里获取代码示例.抛出一种方法时,专业人员更喜欢更具体.主要原因是它使您的API更具可读性.例如,如果你的方法抛出Throwable,那基本上意味着任何事情都可能发生,你的方法也不想处理它,无论如何.但实际上,只有少数事情可能发生:

  • 无论您在方法中进行的其他调用所产生的检查异常
  • 无论检查的异常是什么,你都会根据自己的断言投掷目的
  • 无论你没有计划的任何未经检查的例外
  • 错误(java.lang.Error)对JVM和环境更为全局

通过专门陈述您要抛出的异常,您告诉API的用户他们应该注意什么.例如,当你使用时InputStream,你会注意到大多数方法至少抛出java.io.IOException,这为你提供了一些关于你应该注意什么的有用信息.

编码时,作为一般规则,您希望尽可能保持API的表现力.你基本上有一行代码来显示一个方法的公共API(即它的签名,我猜的注释),所以你想要它完全表达(返回类型,名称,参数,但也抛出异常).

至于捕获throwable并打印堆栈跟踪,我会说你不应该捕获异常,除非你可以做些什么.相反,让它汇总调用堆栈,直到某个类捕获它来执行某些操作.有时候,它可能会一直滚动到主类,我想必须抓住它并打印堆栈跟踪作为最后的手段.基本上,如果你不能对异常采取行动,那么让它上升到调用堆栈.此外,你很难发现自己处于一种你应该使异常沉默的情况下(即抓住它但却什么都不做).在解决问题时,通常会引发问题.

这是一篇有趣但有趣的文章,关于一般滥用异常处理.