重庆网站seo推广公司,杭州的网站设计,北京网络运营推广团队,林州网站建设报价有许多例子说明Java异常处理可能比首次出现时要困难得多#xff0c;Josh Bloch专门将一整章的《 Effective Java》 #xff08;两个版本#xff09;专门用于异常处理。 Java中的检查异常模型 仍然 “ 有争议” 。 我很高兴看到我最近下载的NetBeans 7.4 beta有一些提示… 有许多例子说明Java异常处理可能比首次出现时要困难得多Josh Bloch专门将一整章的《 Effective Java》 两个版本专门用于异常处理。 Java中的检查异常模型 仍然 “ 有争议” 。 我很高兴看到我最近下载的NetBeans 7.4 beta有一些提示至少可以帮助您处理Java异常处理的一些细微差别。 我最近下载了NetBeans 7.4 Beta并在笔记本电脑上安装了此最新版本的NetBeans 。 我下载了“所有”的NetBeans IDE下载包包括GlassFish Server开源版4.0 Apache Tomcat 7.0.41和Groovy支持并将其安装在我的计算机上。 NetBeans的“当前开发版本”中“可能的错误”类别中的两个新提示是“最终块抑制异常”和“抛出在最终块中”。 在此博客文章中我将演示这些提示并简要讨论为什么这些提示有助于改善异常处理。 finally块抑制异常 正如James Stauffer的 “ 不要在finally子句中返回 ”之类的帖子中所记录的以及Java的try-finally返回设计问题之类的论坛中所记录的那样通常都认为从finally块中返回方法是一个坏主意。 接下来显示这种不良Java编码实践的示例。 最终阻止异常的示例 private void throwException() throws Exception
{throw new Exception(A checked exception!);
}/*** Demonstrate NetBeans hint The return statement in the finally block* discards unhandled exceptions by returning a value from the finally* block.* * return Integer value that is really meaningless in this case.* throws RuntimeException This exception is always thrown.*/
public int demonstrateReturnFromFinallyBlock()
{int value 5;try{value 7;throwException();}catch (Exception exception){throw new RuntimeException(exception);}finally{return value;}
} 当执行以上代码片段中的方法demonstrateReturnFromFinallyBlock()时输出如下所示 返回值7 尽管可能有人期望demonstrateReturnFromFinallyBlock()方法抛出运行时异常而不是返回7的整数值因为该方法的Javadoc甚至做广告但实际上由于“ return”语句中的return语句实际上丢弃了“始终抛出”异常。 finally挡住了。 这是一个潜在的令人讨厌的问题可能仅在运行时而不是在编译时才明显。 幸运的是NetBeans 7.4 beta包含有关此潜在问题的提示如以下屏幕快照所示 上面的屏幕快照演示了NetBeans 7.4 beta通过在黄色块中加下划线来警告finally块中的return语句的情况。 它还显示当将鼠标悬停在带有黄色下划线的代码上时NetBeans编辑器将提示“ finally”块中的“ return”语句将丢弃未处理的异常。” 通过将-Xlintfinally传递给javac编译器也可以找到相同的条件。 显然这可以在命令行上完成就像我以前在javac的-Xlint Options中 javac.compilerargs-Xlint:finally的一样但是下一个屏幕快照显示了通过-Xlint:finally规范在NetBeans中所做的相同操作-Xlint:finally通过project.properties设置javac.compilerargs-Xlint:finally 。 在“最终”块内“抛出” 从finally块内部引发异常通常是一个坏主意因为它将隐藏在该finally块的关联try块中引发的任何异常。 下一个代码清单显示了这种错误形式的示例。 /*** Demonstrate NetBeans hint warning that throwing an exception from a* finally block is a bad idea because it hides the original exception.*/
public void demonstrateThrowFromFinallyBlock()
{Integer twoDividedByZero null;try{twoDividedByZero 2 / 0;}finally{if (twoDividedByZero null){throw new RuntimeException(Cannot calculate quotient with division.);}}
} 有人可能认为执行上述方法会导致引发ArithmeticException异常而当引发更一般的和父项 RuntimeException异常时可能会感到有些惊讶。 下一个屏幕快照显示此情况的NetBeans 7.4 beta警告。 将鼠标悬停在带有黄色下划线的代码上会显示NetBeans警告“finally块中的throw语句可能会隐藏原始异常。” 上面的屏幕快照显示了这正是在这种情况下发生的情况 ArithmeticException及其堆栈跟踪被finally块抛出的RuntimeException隐藏了。 如果我注释掉从finally块抛出异常的行则原始异常将再次可用。 下一个屏幕快照对此进行了演示。 即使启用-Xlint:all 或仅启用-Xlint 也不会警告从finally块引发异常的不良形式。 在此特定示例中 -Xlint:devzero 或-Xlint:all或-Xlint 将显示代码中被零除但通常没有-Xlint警告让javac从中抛出时警告您finally块隐藏了原始异常。 这使该特定的NetBeans提示特别有用。 结论 Java异常处理中有许多细微差别和特殊情况。 NetBeans 7.4 Beta引入了两个新的“可能的错误”提示警告与异常相关的finally块中的危险做法。 这两种情况特别隐蔽因为它们通常不会被编译器捕获尽管可以选择将其作为警告捕获直到运行时才被发现并且不太可能通过阅读和查看代码来发现。 参考 NetBeans 7.4 Beta提示警告我们的JCG合作伙伴 Dustin Marx在Inacted by Actual Events博客上进行了无效的异常处理 。 翻译自: https://www.javacodegeeks.com/2013/09/netbeans-7-4-beta-hints-warn-of-ineffective-exception-handling.html
