P2P系统异常处理方案

1. Java 异常最佳实践

1.1 不要在catch块中吞没异常

空的异常或者会使异常达不到应有的目的，因为它不仅隐藏了错误和异常，同时可能导致你的对象处于不可使用或者脏的状态。忽略异常就如同忽略火警信号一样——当真正的火灾发生时，就没有人能够看到火警信号了。如果在某些特殊情况下需要这样做，至少添加一条注释说明为什么可以忽略这个异常。

//Incorrect way
try {
    someMethod();    
} catch(InvalidArgumentException e){

}

1.2 捕获具体异常子类，不要捕获Exception类、RuntimeException类

假如被调用方法的开发者在方法签名中throws一个新的检查型异常（checked exception）,该开发者的目的是需要调用者处理该类型的异常。如果调用者的代码如下，那么调用者可能永远都不会知道这个变化，并且可能使代码在运行时错误的运行。

另一种情况是被调用方法的开发者在方法块中throw一个非检查型异常(unchecked exception)，那么调用者永远都不会知道这个变化，捕获了不该捕获的非检查异常，从而可能导致代码错误的运行。

//Incorrect way
try {
    someMethod();
} catch (Exception e) {
    LOGGER.error("method has failed", e);
}

1.3 不要捕获Throwable类

捕获Throwable类可能会导致很严重的问题，因为Java的Error类也是Throwable的子类，该类代表不可挽回的错误产生，这种错误甚至连JVM都不能处理。

//Incorrect way
try {
    someMethod();
} catch (Throwable e) {
    LOGGER.error("method has failed", e);
}

1.4 要么抛出，要么打印日志，不要两个都做

如下代码会导致在日志文件中打印多个错误日志信息，对查阅日志的工程师来说就是一个噩梦。

//Incorrect way
try {
    someMethod();
} catch (InvalidArgumentException e) {
    LOGGER.error("method has failed", e);
    throw e;
}    

1.5 永远不要在finally块中抛出异常

try {
    someMethod();  //Throws exceptionOne
} finally {
    cleanUp();    //If finally also threw any exception the exceptionOne will be lost forever
}

public class EntityNotFoundException extends RuntimeException {

    private final UMSErrorCode code;
    private final Object[] args;

    public EntityNotFoundException(UMSErrorCode errorCode, Object... args) {
        super(new MessageFormat(errorCode.getMessageTemplate()).format(args));
        this.code = errorCode;
        this.args = args;
    }

    public EntityNotFoundException(UMSErrorCode errorCode, Throwable cause, Object... args) {
        super(new MessageFormat(errorCode.getMessageTemplate()).format(args), cause);
        this.code = errorCode;
        this.args = args;
    }

    public UMSErrorCode getCode() {
        return code;
    }

    public Object[] getArgs() {
        return args;
    }
}

2.4 使用commons-lang 2.5

LOGGER.error(ExceptionUtils.getFullStackTrace(e));

2.5 日志打印

在多线程并发环境下，多个线程的日志都打印在同一个日志文件中, 需要区分哪些信息是在同一个线程输出的。log4j已经提供了一种默认的实现方式，就是使用PatternLayout，在设定输出格式的时候增加%t参数，这样会输出各个线程的线程名称，这样我们就可以根据线程名称区分哪些内容是同一个线程输出出来的。但是如果是一个线程池，池中的线程会被重复利用的情况下，日志会重复打印这个线程名称。为了更好的让日志阅读者更方便的阅读日志，我们可以再使用log4j的MDC，具体的MDC的实现如下：

@Provider
@PreMatching
public class LogMDCFilter implements ContainerRequestFilter, ContainerResponseFilter {

    private static final String REQUEST_UID = "R_UID";
    private static final Random RANDOM = new Random();

    @Override
    public void filter(ContainerRequestContext requestContext) throws IOException {
        MDC.put(REQUEST_UID, getRUID(8));
    }

    @Override
    public void filter(ContainerRequestContext requestContext, ContainerResponseContext responseContext) throws IOException {
        MDC.clear();
    }

    private String getRUID(int len) {
        StringBuffer uid = new StringBuffer();
        for (int i = 0; i < len; i++) {
            int rand = RANDOM.nextInt(1000);
            int mod36 = rand % 36;
            encodeAndAdd(uid, mod36);
        }
        return uid.toString();
    }

    private void encodeAndAdd(StringBuffer ret, long mod36Val) {
        if (mod36Val < 10) {
            ret.append((char) (((int) '0') + (int) mod36Val));
        } else {
            ret.append((char) (((int) 'a') + (int) (mod36Val - 10)));
        }
    }

}

然后在输出格式中增加%X{R_UID}参数。注意在进入Jersey Filter之前或者Jersey已经返回Response，MDC的值都为空。