在Java编程中,Sun推荐利用检查异常处理程序中的错误。检查异常类直接或间接地继承了java.lang.Exception,在继承树中不包含java.lang.RuntimeException。检查异常使得代码中充满了try...catch...finally之类的语句,被很多人认为是对代码的一种“毒化”,所以,多数人的想法恰恰和Sun的建议相反,推荐使用运行时刻的异常处理机制。运行时刻异常类直接或间接地继承了java.lang.RuntimeException,处理这种异常类的实例并不强制需要在代码中加入try...catch之类的语句,从而使得代码变得清晰明了,增加了可读性。
从本质上看,检查异常代表了一种“可恢复”的问题,也就是说,在出现了异常之后,程序还是可以继续运行下去的;而运行时刻异常则代表严重的问题,即出现运行时刻异常,往往代表程序出了严重的问题,不能再继续运行。Sun在设计Java的语言的时候,就是出于这种考虑,推荐程序员使用检查异常的。如果我们把异常看成是一种对方法在调用中有可能出现的问题的一种声明,无疑检查异常在这时更能让代码的阅读者明确该方法的所有功能。检查异常的麻烦之处在于调用时繁琐的try...catch...finally语法。到底应该使用那种异常,对此每个人都有不同的看法,而且在Java世界中总能引发很大的争议。我们在具体编码中,应该根据自身的运行环境和技术要求来确定。对于Web这个应用领域,对于运行时刻异常的使用要更为慎重。
我们知道,Java的Web应用最终都要归为Servlet的运行,Servlet本身就在service、doPost、doGet等方法中抛出了ServletException和IOException,这两个都是检查异常。如果在doPost、doGet等方法中有Runtime异常实例抛出,造成的后果是比较严重的,它会使当前的Web服务器销毁掉对应的Servlet实例,整个Web站点将变得不可用,只有重新载入当前的Web程序才能恢复正常,这相当于整个Web站点当掉了,在实际运行中是不被允许的。
现在很多的一些框架,为了便于程序员的使用,都采用了运行时刻异常,比如Spring框架就是这样,如果我们不注意,让Spring的异常实例出现在最终的Servlet中,这是一种很危险的错误。实际上,很多初学者在学习Spring时,往往被浏览器中出现的404错误感到莫名其妙,其实就是由于配置文件等原因,造成Spring抛出运行时刻异常,导致Servlet的实例被销毁,从而使得对应的页面不可用造成的。
从本质上看,检查异常代表了一种“可恢复”的问题,也就是说,在出现了异常之后,程序还是可以继续运行下去的;而运行时刻异常则代表严重的问题,即出现运行时刻异常,往往代表程序出了严重的问题,不能再继续运行。Sun在设计Java的语言的时候,就是出于这种考虑,推荐程序员使用检查异常的。如果我们把异常看成是一种对方法在调用中有可能出现的问题的一种声明,无疑检查异常在这时更能让代码的阅读者明确该方法的所有功能。检查异常的麻烦之处在于调用时繁琐的try...catch...finally语法。到底应该使用那种异常,对此每个人都有不同的看法,而且在Java世界中总能引发很大的争议。我们在具体编码中,应该根据自身的运行环境和技术要求来确定。对于Web这个应用领域,对于运行时刻异常的使用要更为慎重。
我们知道,Java的Web应用最终都要归为Servlet的运行,Servlet本身就在service、doPost、doGet等方法中抛出了ServletException和IOException,这两个都是检查异常。如果在doPost、doGet等方法中有Runtime异常实例抛出,造成的后果是比较严重的,它会使当前的Web服务器销毁掉对应的Servlet实例,整个Web站点将变得不可用,只有重新载入当前的Web程序才能恢复正常,这相当于整个Web站点当掉了,在实际运行中是不被允许的。
现在很多的一些框架,为了便于程序员的使用,都采用了运行时刻异常,比如Spring框架就是这样,如果我们不注意,让Spring的异常实例出现在最终的Servlet中,这是一种很危险的错误。实际上,很多初学者在学习Spring时,往往被浏览器中出现的404错误感到莫名其妙,其实就是由于配置文件等原因,造成Spring抛出运行时刻异常,导致Servlet的实例被销毁,从而使得对应的页面不可用造成的。