Jersey框架的统一异常处理机制
一、背景

写这边文章源于有朋友问过java中的checked exception和unchecked exception有啥区别，当时我对其的回答是：我编程时仅用RuntimeException。其实，我说句话我是有前提的，确切的应该这么说：在成熟的开发框架下编写业务代码，我只使用或关注RuntimeException。因为，由于框架往往将异常的处理统一封装，这样以便程序员更好的关注业务代码，而业务的一些错误通常是在系统运行期间发生的，因此业务的异常通常被设计为RuntimeException的子类。

我的回答显然不能让朋友满意！因为，不管是任何一个初学java的都知道，在我们学习IO类和JDBC编程的时候，我们用了大量的try...catch...，这种反复重复的try...catch会让我们对java的异常记忆深刻！初学者往往不清楚java的异常为什么会设计成这个样子，他们通常会对异常只进行简单的处理——在catch块里面简单的把异常打印出来，用的最多的就是这个语句：

代码片段说明

1、数据存储文件：test.properties


在该类中，将checked exception全部转化为unchecked exception（我们自定义的exception），调用sayHello()方法时，不再需要try...catch...

3、业务实现类：TestService.java


启动tomcat就可以了！

做两个测试：
1、

2、


第1个测试，还可以在log中看到如下异常错误：

[2013-08-15 00:25:55] [ERROR] 参数必须小于10com.iteye.redhacker.jersey.exception.ServiceException: must.be.less.than.10at com.iteye.redhacker.jersey.service.TestService.sayHello(TestService.java:20)at com.iteye.redhacker.jersey.delegate.TestResources.sayHello(TestResources.java:21)at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39)at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25)at java.lang.reflect.Method.invoke(Method.java:597)at com.sun.jersey.spi.container.JavaMethodInvokerFactory$1.invoke(JavaMethodInvokerFactory.java:60)at com.sun.jersey.server.impl.model.method.dispatch.AbstractResourceMethodDispatchProvider$TypeOutInvoker._dispatch(AbstractResourceMethodDispatchProvider.java:185)at com.sun.jersey.server.impl.model.method.dispatch.ResourceJavaMethodDispatcher.dispatch(ResourceJavaMethodDispatcher.java:75)at com.sun.jersey.server.impl.uri.rules.HttpMethodRule.accept(HttpMethodRule.java:288)at com.sun.jersey.server.impl.uri.rules.ResourceClassRule.accept(ResourceClassRule.java:108)at com.sun.jersey.server.impl.uri.rules.RightHandPathRule.accept(RightHandPathRule.java:147)at com.sun.jersey.server.impl.uri.rules.RootResourceClassesRule.accept(RootResourceClassesRule.java:84)at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1483)at com.sun.jersey.server.impl.application.WebApplicationImpl._handleRequest(WebApplicationImpl.java:1414)at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1363)at com.sun.jersey.server.impl.application.WebApplicationImpl.handleRequest(WebApplicationImpl.java:1353)


关于其他的一些测试，大家可以去尝试一下，比如故意把test.properties删除，当找不到要读取的文件时，checked exception是如何转化为我们自己定义个unchecked exception，并记录下了日志，返回给客户端标准的http错误状态码和错误信息。

四、总结

1、通过jersey框架我们不难看出，在web项目开发来讲，对于checked exception和unchecked exception的处理我们尽可能在框架层面就进行了统一处理，以便我们更加关注与业务的实现。

2、如果是非web项目，我想，程序架构设计者也应当尽量统一的处理异常；如果不做统一处理，当遇到checked exception，我们应当对其进行恰当的异常处理，而不是不是简单的做一个e.printStackTrace()的处理；如果我们不能恢复异常，那我们至少要将异常的错误信息完整的记录到日志文件中去，以便后续的程序出现故障时进行错误排查。

全文（完）