Java 接口的异常设计疑惑

    查看了一些关于Exception的讨论，发现对于如何何时处理异常和使用Checked Exceptions还是Unchecked Exceptions是讨论很激烈的话题呀！如何很好的处理和使用异常，的确是一件不容易的事情？好多时候容易使人感到疑惑！

    对于“疑惑1：在设计接口的时，对于接口方法何时需要声明抛出受检异常或者说所有的接口方法最后都声明抛出受检异常？” 我比较同意前面joachimz的观点。

      接口可以为声明业务性的错误，也就是对于UseCase中的每个异常流声明一个Checked Exception。这个异常最好是抽象的（例如，一个从文件、数据库或者 JNDI 装载资源的方法在不能找到资源时，应该抛出某种 ResourceNotFound 异常，而不是更底层的 IOException 、 SQLException 或者 NamingException ，就像Bloch 在《Effective Java》中提出的第 43 条的提到的：“方法在遇到失败时应该抛出一个异常，但是该异常应该反映该方法做什么，而不是它如何做。”）.

   public interface IBusiness{ 

         public void method() throws BusinessException1，BusinessException2，。。。;

   }

      要做到以上的情况，必须要对业务进行透彻的分析，清楚的知道正常的业务流程和会出现那些错误的业务流程（从业务上说的错误），这样才能设计出完善的接口来。否则，如果接口定义不完善，以后发现还有错误流程没考虑进去那以后改起接口来将是一个灾难呀。

      我个人的想法：是否能将业务尽量的细粒度化，使得容易明确业务的所有错误和正常的流程，来避免接口重构（还请各位大大指教）？

    在一些项目和开源的项目看到过的一种解决方式：在接口声明中使用一个抽象的业务异常类，在具体接口实现中抛出这个抽象类的子类。
    
    public interface IBusiness{

          public void method() throws AbstractBusinessException;

    }

    public class BusinessImplA implements IBusiness{

         public void method() throws SpecificBusinessException1 {
               //业务操作
         }
  
    }

    public class BusinessImplB implements IBusiness{

         public void method() throws SpecificBusinessException2 {
               //业务操作
         }
  
     }

     注：AbstractBusinessException继承自Exception，SpecificBusinessException1，SpecificBusinessException2 继承AbstractBusinessException。

     使用方式一：

         每个具体的业务异常类（如SpecificBusinessException1这样的）本身表示具体的一个业务错误，而接口声明的AbstractBusinessException只是为了能在子类中抛出具体的业务异常。带来的好处之一是当以后发现需要添加新的业务错误（添加新的业务异常）时候，无需修改客户端代码。

         我觉得这种使用方式是不合理的,这样其实把一个接口方法的责任约定方式到了不同的地方（实现类的方式签名中）。接口的实现是无法预期的，客户端难以在出现异常时候确定具体是那个错误（除非客户端程序员能够获取到并且阅读所有的实现类（包括现在实现和将来实现）的API，但这是不可能的）并且进行相应的处理，此时的异常仅仅是对业务执行的错误的指示，无法成为进行恢复或近一步操作的指示。这种方式不值得提倡，因为我们应该在前期就透却全面的分析业务，避免出现遗漏业务流程的情况存在；而对于业务的变更，则应该选择重构。

     使用方式二：

         对异常编码，子类只是简单的包含不同的错误码，定义一个统一的异常字典。客户端获取异常后获取到错误码根据其进行相应处理。

         以下为耶鲁CAS的中的代码摘要：

         public abstract class AuthenticationException extends Exception {

             private String code;

             public AuthenticationException(final String code) {
                   this.code = code;
             }
             .....
         }

       public class BadCredentialsAuthenticationException extends AuthenticationException {

            public static final BadCredentialsAuthenticationException ERROR = new BadCredentialsAuthenticationException();

            private static final String CODE = "error.authentication.credentials.bad";

             public BadCredentialsAuthenticationException() {
                   super(CODE);
             }
             .....
       }

       我觉得这种使用方式就比较合理了，不过这种合理性同样是建立在前期对业务的透却全面的分析基础上。