编程中一个很常见的问题，有帮助的

第一种为什么要抛出E1,E2,E3....?

理论上异常是用来处理，而不是简单抛出的。Test1应该处理掉E1...Ex中的大部分异常，仅仅抛出少数异常。

  我晕！

   从结构上说，我选第二种！理由：结构清楚，便于封装。代码易测试，易重用。

我估计，楼主对oo没有很好的理解

直接由a调用b、c、d。
如果a、b、c、d都是类，则减少类之间的耦合关系。
如果a、b、c、d都是方法，则减少方法直接的耦合关系

能否给个应用场景？否则就是完全无意义的讨论。
这是需要根据应用需求决定方法划分的粒度问题，而且LZ给的例子也有误导性。
“第一个”testX()都缺少自己的logicCode

第一个  
public void test1() throws E2,E3,E4,E5,E6{  
    test2();
    logicCode1();
}
第二个
public void test1() throws E2,E3,E4,E5,E6{
    logicCode1();
}  

问题不在于test()该怎么调用下层方法，
而在于test1()是否要包含调用test2()？！
test1是否要被其他上层代码调用

我选的话也会选第二种，这样也便于阅读。
对于异常处理的话就要看是在什么情况下，如果你这个类是在最底层，做为一个Util类的话，直接往外面抛比较好，如果外部调用出了什么异常，就可以知道是什么问题。

应该选择第二种，起码重用性比较强！
对于异常处理，一般只是在业务层捕获吧，底层的话尽量是抛出

是的，我不是想要大家帮我解决问题。我是想讨论下这个问题。

如果现在的代码是第一种实现，那么重构成第二种的话，会碰见什么问题呢？

大多数程序员并不是说现架构再编码，很容易出现 A函数产生一个C结果  而C结果是B函数的入参，习惯性的就会在 A里面直接调用C。所以第二种实现的接口定义是比较困难的。

异常这块 我只是打个比方，没有具体的含义，目的就是用最坏的代码结构去分析一个问题。

个人觉得第一种有第一种的好处，不过就是层次太多了，第一种看上去不就是三层架构的模式么，只是层次太多了。在test调用test1中，如果test2的方法改变了，或者换成了其他的产品也好，都不会影响上层的调用方式即test1的接口不变。

就是第二个。
看过一个文章，说怎么处理异常。
第一：如果能处理异常，就处理了。抛出一个说明性异常
第二：如果能处理一部分，就处理一部分。然后抛出一个其它异常。
第三：如果完全不能处理，那就全部抛出。由上层处理。

用一个BaseException做基类.
你每一个小方法抛一个基于这个BaseException的异常,
再外层捕获的时候用过BaseException的接口方法或者抽象方法.这样不就解决了你的问题吗?
PS:SQLException就是这样做的.