异常处理有两处改进——multicatch和final重抛。要知道它们对我们有什么帮助,请先看一段Java 6代码。下面这段代码试图查找、打开、分析配置文件并处理此过程中可能出现的各种异常:
在Java 6中处理不同的异常
public Configuration getConfig(String fileName) { Configuration cfg = null; try { String fileText = getFile(fileName); cfg = verifyConfig(parseConfig(fileText)); } catch (FileNotFoundException fnfx) { System.err.println("Config file '" + fileName + "' is missing"); } catch (IOException e) { System.err.println("Error while processing file '" + fileName + "'"); } catch (ConfigurationException e) { System.err.println("Config file '" + fileName + "' is not consistent"); } catch (ParseException e) { System.err.println("Config file '" + fileName + "' is malformed"); } return cfg; }
这个方法会遇到的下面几种异常:
这些异常可以分为两大类。一类是文件以某种方式丢失或损坏,另一类是虽然文件理论上存在并且是正确的,却无法正常读取(可能是因为网络或硬件故障)。
如果能把这些异常情况简化为这两类,并且把所有“文件以某种方式丢失或损坏”的异常放在一个catch语句中处理会更好。在Java 7中就可以做到:
在Java 7中处理不同的异常
public Configuration getConfig(String fileName) { Configuration cfg = null; try { String fileText = getFile(fileName); cfg = verifyConfig(parseConfig(fileText)); } catch (FileNotFoundException|ParseException|ConfigurationException e) { System.err.println("Config file '" + fileName + "' is missing or malformed"); } catch (IOException iox) { System.err.println("Error while processing file '" + fileName + "'"); } return cfg; }
异常e的确切类型在编译时还无法得知。这意味着在catch块中只能把它当做可能异常的共同父类(在实际编码时经常用Exception或Throwable)来处理。
另外一个新语法可以为重新抛出异常提供帮助。开发人员经常要在重新抛出异常之前对它进行处理。在前几个版本的Java中,经常可以看到下面这种代码:
try { doSomethingWhichMightThrowIOException(); doSomethingElseWhichMightThrowSQLException(); } catch (Exception e) { ... throw e; }
这会强迫你把新抛出的异常声明为Exception类型——异常的真实类型却被覆盖了。
不管怎样,很容易看出来异常只能是IOException或SQLException。既然你能看出来,编译器当然也能。下面的代码中用了Java 7的语法,只改了一个单词:
try { doSomethingWhichMightThrowIOException(); doSomethingElseWhichMightThrowSQLException(); } catch (final Exception e) { ... throw e; }
关键字final表明实际抛出的异常就是运行时遇到的异常——在上面的代码中就是IOException或SQLException。这被称为final重抛,这样就不会抛出笼统的异常类型,从而避免在上层只能用笼统的catch捕获。
上例中的关键字final不是必需的,但实际上,在向catch和重抛语义调整的过渡阶段,留着它可以给你提个醒。
Java 7对异常处理的改进不仅限于这些通用问题,对于特定的资源管理也有所提升,我们马上就会讲到。
以上就是本次介绍的全部知识点,希望我们整理的内容能够帮助到大家。
我正在php中创建一个非常简单的注册表单,当前当用户尝试注册时,将弹出一个带有succes或fail消息的javascript警报。 现在,我想捕获sql异常,以显示用户名或电子邮件是否已经在数据库中执行,而不是标准的失败消息。 这是我目前拥有的代码: 我如何检查是否电子邮件或用户名已经在数据库中?这两个变量在数据库中都是唯一的。
本文向大家介绍浅谈java异常处理(父子异常的处理),包括了浅谈java异常处理(父子异常的处理)的使用技巧和注意事项,需要的朋友参考一下 我当初学java异常处理的时候,对于父子异常的处理,我记得几句话“子类方法只能抛出父类方法所抛出的异常或者是其子异常,子类构造器必须要抛出父类构造器的异常或者其父异常”。那个时候还不知道子类方法为什么要这样子抛出异常,后来通过学习《Thinking in Ja
我不知道该怎么办。 当我试图从解析器获取语法错误的数量时,它显示0。 编辑: 它返回null。
Blade 内置了 异常处理器,在开发者模式下它会将异常输出在前端页面,并在控制台打印堆栈信息,生产环境只打印在控制台。 有些时候不满足我们的需求,这时候就需要自定义异常处理了,比如针对某个自定义的异常进行特殊处理。 我们用一个例子来解释如何操作。 定义了一个名为 TipException 的运行时异常类,用于输出错误消息到前台。 按照上面对异常的处理情况这个异常的堆栈信息会被输出在控制台,生产环
任何方法都可以抛出不同类型的异常。这些异常可能是需要应用程序重新部署来解决的编程错误,或者是不需要重新部署但可以解决的暂时性错误。 Hangfire可以处理所有内部的(属于Hangfire本身)和相关的外部方法(任务,过滤器等)的异常,因此不会导致整个应用程序被关闭。所有内部异常都被记录(所以不要忘记 启用日志),最糟糕的情况是导致后台任务被暂停并延时重试 10 次。 当Hangfire遇到在执行
我们在编写程序的时候,经常需要对异常情况做处理。比如,当一个数试图除以 0 时,我们需要捕获这个异常情况并做处理。你可能会使用类似 if/else 的条件语句来对异常情况做判断,比如,判断除法的分母是否为零,如果为零,则打印错误信息。 这在某些简单的情况下是可以的,但是,在大多数时候,我们应该使用 Python 的异常处理机制。这主要有两方面的好处: 一方面,你可以选择忽略某些不重要的异常事件,或