`
redhacker
  • 浏览: 495914 次
  • 性别: Icon_minigender_1
  • 来自: 北京
社区版块
存档分类
最新评论

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

    博客分类：
  • REST
 
阅读更多
一、背景

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

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


我们还与一些记忆，比如数组越界这类的异常： 
java.lang.ArrayIndexOutOfBoundsException: 6

这也会使我们记忆犹新，因为在我们调试程序的时候，它经常出现！我们会发现这类异常并不需要在代码里用try...catch...去捕获它。

上面两个例子，其实就是朋友问到的checked exception和unchecked exception，需要try...catch...的异常是checked exception，不需要的则是unchecked exception。如果要说他们的区别，我说他们一个要try...catch...，一个不需要，这样的回答行吗？我认为这样的回答是苍白的。有同学会进一步说，try...catch很显然，是强制要求抛出异常的方法调用者显式的处理异常，那e.printStackTrace()算不算处理了异常，我认为那只算是一种简单懒惰的处理方式吧！那什么样的处理方式算是高明的，java语言设计者其实是期望发生异常后，调用者能够在catch里将异常恢复回来，使得程序能够继续执行下去。但是，“聪明的程序员都是懒惰的”呵呵，大多数情况下我们选择异常出现后只进行记录日志和UI用户提示，后面我会结合jersey框架，说说其中的统一异常处理。读到这里，有人会说，那checked exception和unchecked exception异常的区别就是，一个需要处理，一个不需要处理。这个回答正确吗？我认为是错误的！我的观点是：无论是checked exception还是unchecked exception，我们都要进行处理！

上一段，我们似乎还是没有解决checked exception和unchecked exception的区别，我认为如何给出答案并不重要，重要的是我们怎么去处理这些异常，以及我们如何在开发时使用异常。

我的观点是（Web系统开发）：

1、在框架层面封装checked exception，将其转化为unchecked exception，避免开发过程中编写繁冗的try...catch代码。

2、业务层面的开发，根据程序代码职责定义不同的RuntimeException(它就是unchecked exception，一般定义为RuntimeException的子类)

3、通过前两个观点，系统中自定义的异常将只存在unchecked exception，系统只在于客户端交换数据的上层，设置统一异常处理机制，并将一些异常转化为用户所能理解的信息传达给用户。

4、其他如业务层，数据持久层，等底层只负责将异常抛出即可，但要注意不要丢失掉异常堆栈（这一点是初学者容易犯的一个错误）。


背景说的够长了！让我们进入正题吧，看看Jersey框架的统一异常处理器是怎样使用的！

二、jersey框架的统一异常处理机制

有如下约定：

1、示例采用jersey1.x版本
2、spring版本为2.5
3、为了简单起见，示例项目不采用Maven机制

示例的业务场景说明：

1、我们通过读取一个properties配置文件，配置文件的内容为：

引用
key1=hello
key2=iteye.com


2、发起一个http://localhost:8888/a/resources/test?n=11的GET请求，要求n为数字，且必须小于10，如果n错误，将产生一个unchecked exception错误。

3、本示例中数据访问层将读取一个文件，读取文件错误将会产生checked exception错误。

示例项目结构设计



代码片段说明

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

key1=hello
key2=iteye.com

这就是我们要读取的文件，为了简单起见，它是一个properties文件。

2、数据访问类：TestDao.java 

package com.iteye.redhacker.jersey.dao;

import java.io.IOException;
import java.io.InputStream;
import java.net.URL;
import java.util.Properties;

import org.springframework.stereotype.Component;

import com.iteye.redhacker.jersey.exception.DaoException;
import com.iteye.redhacker.jersey.exception.ExceptionCode;

@Component
public class TestDao {
	public String sayHello() {
		ClassLoader classLoader = TestDao.class.getClassLoader();
		String iniFile = "com/iteye/redhacker/jersey/dao/test.properties";
		URL url = classLoader.getResource(iniFile);
		InputStream is;
		try {
			is = url.openStream();
		} catch (IOException e) {
			throw new DaoException(e, ExceptionCode.READ_FILE_FAILED);
		}
		Properties proper = null;
		try {
			if (proper == null) {
				proper = new Properties();
			}
			proper.load(url.openStream());
		} catch (IOException e) {
			throw new DaoException(e, ExceptionCode.READ_CONFIG_FAILED);
		} finally {
			if (is != null) {
				try {
					is.close();
					is = null;
				} catch (IOException e) {
					throw new DaoException(e, ExceptionCode.COLSE_FILE_FAILED);
				}
			}
		}
		return proper.getProperty("key1") + "," + proper.getProperty("key2");
	}
}

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

3、业务实现类：TestService.java 

package com.iteye.redhacker.jersey.service;

import org.springframework.beans.factory.annotation.Autowired;
import org.springframework.stereotype.Component;

import com.iteye.redhacker.jersey.dao.TestDao;
import com.iteye.redhacker.jersey.exception.ExceptionCode;
import com.iteye.redhacker.jersey.exception.ServiceException;

@Component

public class TestService {
	
	@Autowired
	private TestDao testDao;
	
	public String sayHello(int n) {
		// 业务上规定n不能大于10 
		if (n > 10) {
			throw new ServiceException(ExceptionCode.MUST_BE_LESS_THAN_10);
		}
		return testDao.sayHello();
	}

	/**
	 * @param testDao the testDao to set
	 */
	public void setTestDao(TestDao testDao) {
		this.testDao = testDao;
	}
}

在该类中，我们抛出了一个自己的业务异常，它是一个unchecked exception。

注意：我们使用@Autowired注入了TestDao类，@Autowired是Spring提供的一个注解；我们必须提供一个要注解属性的Set方法，否则注解将失败。

4、请求接入类：TestResources.java 

package com.iteye.redhacker.jersey.delegate;

import javax.ws.rs.GET;
import javax.ws.rs.Path;
import javax.ws.rs.Produces;
import javax.ws.rs.QueryParam;
import javax.ws.rs.core.MediaType;

import com.iteye.redhacker.jersey.service.TestService;
import com.sun.jersey.api.spring.Autowire;

@Path("/test")
@Autowire
public class TestResources {
	
	private TestService testService;
	
	@GET
	@Produces(MediaType.TEXT_PLAIN)
	public String sayHello(@QueryParam("n") int n) {
		return testService.sayHello(n);
	}

	/**
	 * @param testService the testService to set
	 */
	public void setTestService(TestService testService) {
		this.testService = testService;
	}
	
	
}


这里是jersey定义的一个资源，我们可以这样访问这个资源:发起GET请求，访问URI为/resources/test，可以传递一个查询参数n，例如：/resources/test?n=1

注意：我们使用了@Autowire并不是Spring的一个注解，它是jersey-srping集成包的一个注解；我们必须提供一个要注解属性的Set方法，否则注解将失败。

5、统一异常处理器类：ExceptionMapperSupport.java 

package com.iteye.redhacker.jersey.jaxrs;

import javax.servlet.ServletContext;
import javax.servlet.http.HttpServletRequest;
import javax.ws.rs.core.Context;
import javax.ws.rs.core.MediaType;
import javax.ws.rs.core.Response;
import javax.ws.rs.core.Response.Status;
import javax.ws.rs.ext.ExceptionMapper;
import javax.ws.rs.ext.Provider;

import org.apache.log4j.Logger;
import org.springframework.web.context.WebApplicationContext;

import com.iteye.redhacker.jersey.exception.BaseException;
import com.iteye.redhacker.jersey.exception.ExceptionCode;
import com.sun.jersey.api.NotFoundException;

/**
 * 统一异常处理器
 */
@Provider
public class ExceptionMapperSupport implements ExceptionMapper<Exception> {
	private static final Logger LOGGER = Logger
			.getLogger(ExceptionMapperSupport.class);

	private static final String CONTEXT_ATTRIBUTE = WebApplicationContext.ROOT_WEB_APPLICATION_CONTEXT_ATTRIBUTE;

	@Context
	private HttpServletRequest request;

	@Context
	private ServletContext servletContext;

	/**
	 * 异常处理
	 * 
	 * @param exception
	 * @return 异常处理后的Response对象
	 */
	public Response toResponse(Exception exception) {
		String message = ExceptionCode.INTERNAL_SERVER_ERROR;
		Status statusCode = Status.INTERNAL_SERVER_ERROR;
		WebApplicationContext context = (WebApplicationContext) servletContext
				.getAttribute(CONTEXT_ATTRIBUTE);
		// 处理unchecked exception
		if (exception instanceof BaseException) {
			BaseException baseException = (BaseException) exception;
			String code = baseException.getCode();
			Object[] args = baseException.getValues();
			message = context.getMessage(code, args, exception.getMessage(),
					request.getLocale());

		} else if (exception instanceof NotFoundException) {
			message = ExceptionCode.REQUEST_NOT_FOUND;
			statusCode = Status.NOT_FOUND;
		} 
		// checked exception和unchecked exception均被记录在日志里
		LOGGER.error(message, exception);
		return Response.ok(message, MediaType.TEXT_PLAIN).status(statusCode)
				.build();
	}
}


在这个类里面我们处理了我们定义的unchecked exception异常，还处理了系统未知的exception(包括未知的unchecked exception和checked exception)。我们的处理方式是：a、记录异常日志；b、向客户端抛一个标准的http标准错误状态码和错误消息，由客户端对错误信息进行自行处理，值得说明的是，这种处理方式是REST所提倡的，它恰当的使用了HTTP标准状态码；

在这个类中我们还使用了spring的国际化配置组件，用于对系统抛出的错误key进行国际化转换，这有利于我们的项目国际化升级。

6、自定义异常基类：BaseException.java 

package com.iteye.redhacker.jersey.exception;

/**
 * 异常基类，各个模块的运行期异常均继承与该类
 */
public class BaseException extends RuntimeException {

    /**
     * the serialVersionUID
     */
    private static final long serialVersionUID = 1381325479896057076L;

    /**
     * message key
     */
    private String code;

    /**
     * message params
     */
    private Object[] values;

    /**
     * @return the code
     */
    public String getCode() {
        return code;
    }

    /**
     * @param code the code to set
     */
    public void setCode(String code) {
        this.code = code;
    }

    /**
     * @return the values
     */
    public Object[] getValues() {
        return values;
    }

    /**
     * @param values the values to set
     */
    public void setValues(Object[] values) {
        this.values = values;
    }

    public BaseException(String message, Throwable cause, String code, Object[] values) {
        super(message, cause);
        this.code = code;
        this.values = values;
    }
}

这个类定义了项目异常类的基本模板，其他异常继承与它。值得注意的是，它巧妙的利用了国际化配置的一些特征，甚至可以抛出下面这样定义的一个错误消息，通过传递参数的方式，复用错误信息： 

第{0}个{1}参数错误


7、其他异常基本差不多，只是类型不同，我们看一下DaoException.java 

package com.iteye.redhacker.jersey.exception;

public class DaoException extends BaseException {

	/**
	 * Constructors
	 * 
	 * @param code
	 *            错误代码
	 */
	public DaoException(String code) {
		super(code, null, code, null);
	}

	/**
	 * Constructors
	 * 
	 * @param cause
	 *            异常接口
	 * @param code
	 *            错误代码
	 */
	public DaoException(Throwable cause, String code) {
		super(code, cause, code, null);
	}

	/**
	 * Constructors
	 * 
	 * @param code
	 *            错误代码
	 * @param values
	 *            一组异常信息待定参数
	 */
	public DaoException(String code, Object[] values) {
		super(code, null, code, values);
	}

	/**
	 * Constructors
	 * 
	 * @param cause
	 *            异常接口
	 * @param code
	 *            错误代码
	 * @param values
	 *            一组异常信息待定参数
	 */
	public DaoException(Throwable cause, String code, Object[] values) {
		super(code, null, code, values);
	}

	private static final long serialVersionUID = -3711290613973933714L;

}

它继承了BaseException，当抛出这个异常时，我们就从异常名字上直接初步判断出，错误出自Dao层。

8、errMsg.properties用于定义异常信息，来看一下： 

read.file.failed=读取文件失败
read.config.failed=读取配置项失败
must.be.less.than.10=参数必须小于10
colse.file.failed=关闭文件失败
request.not.found=没有找到相应的服务
internal.server.error=服务器内部错误


三、部署及测试

你可以在本文附件里下载到源码。导入eclipse后，查看源码。

部署很简单，只要将你的tomcat/config/server.xml里加入： 
<Host>
...
<Context path="/a"  reloadable="true" docBase="D:/workspace/test/JerseyExceptionMapperTest/web"  />

</Host>

启动tomcat就可以了！

做两个测试：
1、

2、


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

[2013-08-15 00:25:55] [ERROR] 参数必须小于10
com.iteye.redhacker.jersey.exception.ServiceException: must.be.less.than.10
	at 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()的处理；如果我们不能恢复异常，那我们至少要将异常的错误信息完整的记录到日志文件中去，以便后续的程序出现故障时进行错误排查。

全文（完）

如果您觉得本文对您有益，请点击博文后的google广告或在博主微店(美鲜果店)订购一份水果以表感谢，对作者表示支持，谢谢！
  • 大小: 38.3 KB
  • 大小: 6.1 KB
  • 大小: 5.7 KB
分享到：
REST介绍
评论
25 楼 fanqi77 2017-08-16  
例子中没有体现出 不同自定义exception的用途和区别
24 楼 redhacker 2017-04-12  
u012824908 写道
运行出来以后，提示信息出现乱码，该如何解决呢？

注意你的IDE的编码要为UTF-8
23 楼 u012824908 2015-11-26  
运行出来以后，提示信息出现乱码，该如何解决呢？
22 楼 dongbz 2014-11-14  
正文与评论都让我获益匪浅。
deepthink 写道
在编程中还有一个说法，跟异常也有一点相关性
一般在我们编程中会对进入method的参数进行校验，比如：
class a{
     public String eq(String a,String b){
     if(a == null ){ // check not null
           return null ;
     }

     return a + b;
     }
}


如果我们预期到参数a不可能为null，那么在method中多数情况下都不需要校验，这个好像叫做“立即错误”（好像是这么叫的）；

目的是让预期之外的错误立即得到触发，而不是判断了null之后返回一个null，因为，如果已经预期了a不可能为null，出现了这种情况则说明了代码编写的有错误，这种错误应该立即得到触发而被异常处理系统捕获到才对，所以就不应该再去check not null

这个也是很多开发人员容易忽略的问题。

这里我会用Assert.notNull(obj)
21 楼 redhacker 2014-10-29  
apwy111 写道
你的这个demo下载不了啊？什么情况

可以吧。你下载这个http://redhacker.iteye.com/admin/blogs/267604，更基础一些。
20 楼 apwy111 2014-10-11  
你的这个demo下载不了啊？什么情况
19 楼 redhacker 2014-09-23  
dsxwjhf 写道
请问一下，ExceptionMapperSupport 是怎么起作用的？我按您的方法做了一遍， ExceptionMapperSupport 没有生效。

ExceptionMapperSupport就是异常处理器，你下载源码先运行下我的程序是否能够起作用，再对照看看你的为什么不作用就行了。
18 楼 dsxwjhf 2014-09-21  
请问一下，ExceptionMapperSupport 是怎么起作用的？我按您的方法做了一遍， ExceptionMapperSupport 没有生效。
17 楼 redhacker 2014-06-23  
anranran 写道
1. 检查异常一般为非不为可控制的异常。网络断开，磁盘损坏等。但可恢复。
2. 运行时异常一航为程序本身的BＵＧ。逻辑不对产生。出现一般都没办法恢复。比如空指针等。

Spring把很多ＪＤＢＣ的异常都搞成运行时异常。作为认为这些异常分类抛出为业务层来说也没有任何意议。


嗯，Spring框架的这些异常，我们自己再在自己的开发框架里转化下~~~
16 楼 anranran 2013-08-21  
1. 检查异常一般为非不为可控制的异常。网络断开，磁盘损坏等。但可恢复。
2. 运行时异常一航为程序本身的BＵＧ。逻辑不对产生。出现一般都没办法恢复。比如空指针等。

Spring把很多ＪＤＢＣ的异常都搞成运行时异常。作为认为这些异常分类抛出为业务层来说也没有任何意议。
15 楼 deepthink 2013-08-21  
redhacker 写道
deepthink 写道
在编程中还有一个说法，跟异常也有一点相关性
一般在我们编程中会对进入method的参数进行校验，比如：
class a{
     public String eq(String a,String b){
     if(a == null ){ // check not null
           return null ;
     }

     return a + b;
     }
}


如果我们预期到参数a不可能为null，那么在method中多数情况下都不需要校验，这个好像叫做“立即错误”（好像是这么叫的）；

目的是让预期之外的错误立即得到触发，而不是判断了null之后返回一个null，因为，如果已经预期了a不可能为null，出现了这种情况则说明了代码编写的有错误，这种错误应该立即得到触发而被异常处理系统捕获到才对，所以就不应该再去check not null

这个也是很多开发人员容易忽略的问题。

嗯，如果写一个接口，这个接口的实现，与调用是一个人写的话，接口的为空判断感觉有些多余，因为正如你所说，是预期内的。

如果写一个接口，你来实现这个接口，而调用者你并不知道是谁，这时候我认为，一些参数为空校验对调用者来说是有帮助的，最好是为空时抛一些uncheck exception给调用者，并在接口的docs注释说详细说明什么情况下会抛出参数校验的异常，就对调用者就更加友好了！


如果是对外暴露的话，就说明预期不确定 ~~ 哈哈
14 楼 redhacker 2013-08-21  
deepthink 写道
在编程中还有一个说法，跟异常也有一点相关性
一般在我们编程中会对进入method的参数进行校验，比如：
class a{
     public String eq(String a,String b){
     if(a == null ){ // check not null
           return null ;
     }

     return a + b;
     }
}


如果我们预期到参数a不可能为null，那么在method中多数情况下都不需要校验，这个好像叫做“立即错误”（好像是这么叫的）；

目的是让预期之外的错误立即得到触发，而不是判断了null之后返回一个null，因为，如果已经预期了a不可能为null，出现了这种情况则说明了代码编写的有错误，这种错误应该立即得到触发而被异常处理系统捕获到才对，所以就不应该再去check not null

这个也是很多开发人员容易忽略的问题。

嗯，如果写一个接口，这个接口的实现，与调用是一个人写的话，接口的为空判断感觉有些多余，因为正如你所说，是预期内的。

如果写一个接口，你来实现这个接口，而调用者你并不知道是谁，这时候我认为，一些参数为空校验对调用者来说是有帮助的，最好是为空时抛一些uncheck exception给调用者，并在接口的docs注释说详细说明什么情况下会抛出参数校验的异常，就对调用者就更加友好了！
13 楼 deepthink 2013-08-21  
在编程中还有一个说法，跟异常也有一点相关性
一般在我们编程中会对进入method的参数进行校验，比如：
class a{
     public String eq(String a,String b){
     if(a == null ){ // check not null
           return null ;
     }

     return a + b;
     }
}


如果我们预期到参数a不可能为null，那么在method中多数情况下都不需要校验，这个好像叫做“立即错误”（好像是这么叫的）；

目的是让预期之外的错误立即得到触发，而不是判断了null之后返回一个null，因为，如果已经预期了a不可能为null，出现了这种情况则说明了代码编写的有错误，这种错误应该立即得到触发而被异常处理系统捕获到才对，所以就不应该再去check not null

这个也是很多开发人员容易忽略的问题。
12 楼 deepthink 2013-08-21  
redhacker 写道
deepthink 写道
对于异常的两个观点：
1，只要不是retry或者queue的情况，基本上所有的异常都是需要继续向上抛的，最终交给顶层异常处理机制（应用或者容器）;
2，不会出现需要 e.printStackTrace();的地方，这个代码是不允许有的；这里只会出现两种情况，第一种是打印后不处理异常（继续抛或者记录），这是代码中的大忌；第二种情况是打印后处理异常，那么既然处理了异常，打印异常信息也就变得多此一举了，只会给开发者的团队带来不必要的烦恼。

第1点很认同；
第2点读的不是很明白，其实e.printStackTrace()和log("err msg",e)，都是记录日志，一个会将日志打印到控制台，一个是记录的日志文件，一般为了更清楚方便的查找日志利用log4j等日志组件按照指定的目录，文件去输出日志，这样便于后续诊断系统故障。记录日志就是一种处理异常的方法，如果往上抛异常就不需要再记录了，因为抛就是希望上层去处理，这个观点英雄所见略同！


都是异常处理的方式，一般都是必须向上抛的
打印到控制台和记录到日志文件还是有不同的
1，前者在开发环境的时候不可控，如果团队中的开发人员都在控制台打印信息，那么控制台基本就没法用了；
2，打印到控制台的信息，其实就是System.out.println出来的信息，而不是System.err的信息，不易识别，通过日志的方式，则由日志自动区分具体是用何种输出方式；
3，信息不可拆分，输出到日志的信息（例如用log4j）可以进行分类处理，可也过滤，特别重要的信息要放到独立的日志文件中，例如info,error

目前对于开发人员来说，代码中是不允许出现System.out或者e.printStackTrace这种用法（目前我们公司是这样要求的，而且是基本要求），即使要打印也是由顶层（全局）的异常处理系统去打印，即使没有app级别的异常处理系统，那么也应该直接交给web容器或者jvm处理
11 楼 redhacker 2013-08-21  
deepthink 写道
对于异常的两个观点：
1，只要不是retry或者queue的情况，基本上所有的异常都是需要继续向上抛的，最终交给顶层异常处理机制（应用或者容器）;
2，不会出现需要 e.printStackTrace();的地方，这个代码是不允许有的；这里只会出现两种情况，第一种是打印后不处理异常（继续抛或者记录），这是代码中的大忌；第二种情况是打印后处理异常，那么既然处理了异常，打印异常信息也就变得多此一举了，只会给开发者的团队带来不必要的烦恼。

第1点很认同；
第2点读的不是很明白，其实e.printStackTrace()和log("err msg",e)，都是记录日志，一个会将日志打印到控制台，一个是记录的日志文件，一般为了更清楚方便的查找日志利用log4j等日志组件按照指定的目录，文件去输出日志，这样便于后续诊断系统故障。记录日志就是一种处理异常的方法，如果往上抛异常就不需要再记录了，因为抛就是希望上层去处理，这个观点英雄所见略同！
10 楼 deepthink 2013-08-20  
对于异常的两个观点：
1，只要不是retry或者queue的情况，基本上所有的异常都是需要继续向上抛的，最终交给顶层异常处理机制（应用或者容器）;
2，不会出现需要 e.printStackTrace();的地方，这个代码是不允许有的；这里只会出现两种情况，第一种是打印后不处理异常（继续抛或者记录），这是代码中的大忌；第二种情况是打印后处理异常，那么既然处理了异常，打印异常信息也就变得多此一举了，只会给开发者的团队带来不必要的烦恼。
9 楼 redhacker 2013-08-19  
暗夜骑士0376 写道
我觉得JAX-WS support的异常就两部分，
1. 一个是ExceptionMapper<? extends Throwable>,
2, 一个是自定义一个异常extends WebApplicationException.

对于2，就是自定义一个异常， 配上Response Code， 这一类异常是我们自己handle的。
对于1， 就是无法handle的异常，使用Mapper， 一般handle那种ServerError， NotFoundException之类的。


WebApplicationException extends RuntimeException，是unchecked exception，不需要我们强制try...catch处理的。同样可以被统一异常处理器拦截处理的。

这个是jersey框架层的异常，在resouce层的异常我们可以直接使用这个异常抛出错误，也可以自定义一个异常继承它。

看一下它的一个典型的构造方法：

    /**
     * Construct a new instance with a blank message and specified HTTP status code
     * @param status the HTTP status code that will be returned to the client
     * @param cause the underlying cause of the exception
     * @throws IllegalArgumentException if status is null
     */
    public WebApplicationException(Throwable cause, Response.Status status) {
        this(cause, Response.status(status).build());
    }


这个构造函数跟我传进一个i18n的key的思路是相似的。你可以在ExceptionMapper里去捕获WebApplicationException，取得他的http status code进行更加友好的客户端提示。
8 楼 暗夜骑士0376 2013-08-19  
我觉得JAX-WS support的异常就两部分，
1. 一个是ExceptionMapper<? extends Throwable>,
2, 一个是自定义一个异常extends WebApplicationException.

对于2，就是自定义一个异常， 配上Response Code， 这一类异常是我们自己handle的。
对于1， 就是无法handle的异常，使用Mapper， 一般handle那种ServerError， NotFoundException之类的。
7 楼 redhacker 2013-08-17  
jasperreport 写道

就拿service层的异常处理来说，在TestResources中调用testService.sayHello();如果出现异常的话，在TestResources中程序还是会继续执行的，这是我们不希望的，因为前面已经出现异常了！对不？

对，service层出现异常，jersey框架的异常处理器就会拦截捕获到这个异常，进行异常处理过程了，TestResources调用service方法后面的逻辑肯定不会再执行了！
6 楼 jasperreport 2013-08-17  

就拿service层的异常处理来说，在TestResources中调用testService.sayHello();如果出现异常的话，在TestResources中程序还是会继续执行的，这是我们不希望的，因为前面已经出现异常了！对不？
发表评论

您还没有登录,请您登录后再发表评论

相关推荐

    Jersey框架的统一异常处理机制分析

    以下是使用Jersey框架统一异常处理机制的步骤： 1. 创建自定义的ExceptionMapper类：实现ExceptionMapper接口，为特定的异常类型提供处理逻辑。例如，我们可以创建一个处理所有 RuntimeException 的 mapper 类： `...

    jersey 1.9 框架源码

    9. **错误处理**：Jersey提供了统一的异常处理机制，可以自定义错误处理器，生成符合HTTP状态码的响应。 10. **测试支持**：Jersey Test Framework提供了一套测试工具，可以在不启动服务器的情况下测试REST服务。 ...

    Jersey开发指南

    - **错误处理**：统一处理异常情况，返回恰当的状态码和错误信息。 - **文档编写**：维护清晰的API文档，方便其他开发者理解和使用。 #### 六、社区支持与资源 - **官方文档**：查阅最新的Jersey官方文档获取详细...

    jersey服务demo

    - 添加 `@Provider` 注解的类来扩展 Jersey 功能，例如自定义异常处理器或消息身体读写器。 6. **运行和测试** - 将项目部署到 Servlet 容器中，如 Tomcat。 - 使用浏览器或 HTTP 工具（如 Postman）发送请求到...

    jersey-bundle-1.9.1.jar.zip

    1. **jersey-server**: 提供了处理HTTP请求和响应的基本框架，以及资源定位和映射机制。 2. **jersey-client**: 支持作为客户端，用于发送HTTP请求和接收响应，可以方便地进行RESTful调用。 3. **jersey-spring**: ...

    jersey 实现restful服务

    本教程将重点讲解如何使用Jersey框架来实现RESTful服务。 Jersey是Java语言中一个非常流行的实现RESTful服务的开源库，它是JAX-RS（Java API for RESTful Web Services）规范的一个参考实现。JAX-RS提供了一套标准...

    Jersey 使用手册

    6. **错误处理**：内置的错误处理机制使得开发者能够更轻松地处理服务端或客户端可能出现的各种异常情况。 #### 四、Jersey的安装与配置 1. **添加依赖**：在项目中添加Jersey的相关依赖库。对于Maven项目，可以...

    Build a RESTful Web service using Jersey and Apache Tomcat.

    Jersey还提供了异常映射机制、过滤器和拦截器来增强服务的功能和安全性。 为了在Apache Tomcat服务器上部署Jersey创建的RESTful服务，开发者需要执行一系列步骤，如将Jersey库添加到项目的依赖中，配置web.xml来...

    Jersey 2.5.1 Server jar

    5. **异常处理**：内置的异常映射机制将Java异常转化为HTTP错误状态码，提供统一的错误处理。 6. **客户端API**：Jersey提供了一个强大的客户端API，方便进行服务调用和测试。 7. **性能优化**：2.5.1版本对性能...

    Jersey2中文文档_高清版_带目录可跳转

    3. **过滤器与拦截器**：Jersey2 提供了过滤器（Filter）和拦截器（Interceptor）机制，允许在请求处理之前或之后执行自定义逻辑，如认证、日志记录等。 4. **客户端API**：除了服务器端功能，Jersey2 还提供了...

    JerseyServer

    标题“JerseyServer”暗示我们讨论的是使用Jersey框架构建的Web服务服务器端。Jersey是Java RESTful Web Services（Representational State Transfer，表述性状态转移）的实现，它允许开发者创建和消费RESTful API。...

    服务请求数据包,导包.zip

    Java提供了try-catch语句来捕获和处理异常，同时，使用统一的异常处理机制可以提供更好的用户体验和更健壮的代码。 8. **性能优化**： 对于高并发的服务请求，性能优化至关重要。这可能涉及到线程池的使用、数据库...

    RESTful Web Services with Dropwizard

    - **异常处理**：自定义异常处理器以优雅地处理错误。 - **过滤器**：实现跨切面关注点，如认证、日志记录等。 ##### 5. 配置管理与环境适配 - **配置文件**：使用YAML或JSON格式定义配置。 - **环境感知**：根据...

    Java webService服务端封装

    - **异常处理**：为避免将异常暴露给调用者，应设计统一的异常处理机制，比如全局异常拦截器。 - **性能优化**：合理使用缓存、批量操作等手段提高服务性能。 - **安全性**：实施身份验证和授权，保护敏感数据，...

    基于REST的webservice规范2.0版本

    6. **错误处理**：JAX-RS 2.0提供了一种统一的方式来处理异常，并且可以自定义异常映射规则，提高了异常处理的灵活性和可扩展性。 #### 四、JAX-RS 2.0规范文档概览 根据所提供的部分内容，可以看出该文档为JAX-RS...

    rest_code.rar

    - Jersey是Java中实现JAX-RS（Java API for RESTful Web Services）规范的一个开源框架，用于构建RESTful服务。 - 使用`@Path`注解定义资源路径，`@GET`, `@POST`, `@PUT`, `@DELETE`等注解表示HTTP操作。 - `@...

    rest相关的开发的相关的一些资料

    Spring MVC是Spring框架的一部分，提供了处理HTTP请求和响应的机制，它是构建RESTful服务的核心组件。 2. **RESTful API设计原则** - **资源导向**：每个URL代表一个资源，如/users/1表示用户ID为1的用户资源。 -...

    REST的全部jia包

    错误处理通常涉及异常处理和返回标准的HTTP状态码；Swagger则能自动生成API文档，便于开发者了解和使用API。 总之，"REST的全部jia包"涵盖了从构建RESTful服务的基础框架、数据序列化、安全控制到辅助开发的各个...

    REST介绍文档

    - **异常处理**：提供了灵活的机制来处理和映射异常到合适的HTTP状态码。 - **过滤器和拦截器**：允许在请求和响应的生命周期中插入自定义逻辑。 #### JAX-RS的实施 JAX-RS有多个流行的实现，包括Jersey、RestEasy...

    restful-client

    在这个项目中，特别使用了Jersey 2.13框架，这是一个开源的Java框架，专门用于构建RESTful服务和客户端。 首先，我们要理解RESTful的基本原则： 1. **资源导向**：每个URI（统一资源标识符）代表一个特定的资源，...

Magicbox
Global site tag (gtag.js) - Google Analytics