this条款中的第6项：
尽量不要因为价格而重新抛出异常。如果 重新投掷是必须的，重新抛出相同的例外，而不是 创建一个新的例外。这将带来额外的性能。您 可以在每个图层中添加该异常的附加信息。
嗯但是这违反了层的分离，不是吗？
假设我有一个特定的DAO实现，它会抛出 SQLException
假设我的服务层（或业务层...）从DAO层调用方法，但决定不处理抛出的异常。
如果我将SQLException重新抛出到视图层，我的视图层将不仅会耦合到DAO层，不是吗？
抛出一个新的异常是不对的，以便View在下面的第一层依次 ，而不是两个？
除了性能之外，抛出相同的Exception会带来什么好处？
答案 0 :(得分：5)
如果我将
SQLException重新投射到视图层，我的视图层将不仅会耦合到DAO层，不是吗？
这是绝对正确的。
抛出一个新的异常是不对的，所以View只依赖于下面的第一层，而不是两个？
绝对。如果您的DAO层无法处理来自SQL的异常，它应该捕获它，尽可能多地了解它，并抛出它自己的异常。
考虑一个例子：假设您的DAO图层允许您添加某个属性必须唯一的新项目。 SQL层可能具有唯一约束或唯一索引，以在RDBMS层上强制实施此约束。如果DAO层的调用者尝试保存违反唯一性约束的对象，则会抛出SQL异常。如果你让这个异常传播给调用者，很可能他们不知道如何处理它，甚至可能会向最终用户显示：
ORA-00001：违反了唯一约束（UxPatient_rec_soc）
这个解决方案非常糟糕，但尝试在客户端上理解它的另一种选择更加脆弱。
您的DAO应该捕获异常，确定它对调用者意味着什么，并抛出自己的异常。这样，您就可以独立于调用者更改您的实现。
一般说明：在决定抛出/重新抛出异常时，性能考虑应该是最不重要的因素，因为只有在极少数情况下才会抛出异常。清晰的界面更为重要。
答案 1 :(得分：3)
我同意你的观点，即在你的图层上添加一个更具描述性的异常包装原始图层会更方便。在这种情况下，SQLException可能是一个低级问题，可以通过抛出一个更具描述性的新异常来解释并放入业务环境。
另外请注意，错误处理本身的性能通常不是您想要优化的。因此，与从方法返回相比，抛出异常的速度较慢，但只有在出现问题时才会发生这种情况。 （因为你应该避免使用异常来处理正常的程序流程）
我没有看到抛出相同异常的任何优势，除非您真的无法通过包装来添加任何信息。在那种情况下不要这样做。