异常的处理

多层结构中的异常最终处理一般设在业务逻辑层比较好,业务逻辑以下的层次一般捕获或者预先发现错误,然后封装,再向外层抛出去,到业务逻辑层,错误的信息基本已经完备,再根据业务的实际情况,选择抛出,忽略或者其他的处理方式.如果再往外层处理异常的话,则会出现过多的try catch语句,再往内层处理异常的话,得到的异常信息不能很好的与业务相关,不容易纠正错误.

至于异常的抛出,我认为随时发现,随时抛出也不错,因为象下标越界,写只读数据等误操作,很容易发现,如果依赖framework捕获抛出的话,效率上损失不小.

首先，比较严谨的设计方法中，以“没有异常”为目的。例如上面说的“增加用户”的功能，你是否在设计中考虑到用户重复的问题呢？通常要求设计文档中考虑到这个，而不是推给程序员去处理。此时，“正常的逻辑”中应该检查异常信息，明确了处理流程。

因此，假设我们都同意程序员不知道如何处理的异常是表达设计人员由于技术水平而没有考虑到的逻辑异常，这种处理就应该丢给界面去处理。当然这里的界面不一定是最终用的操作终端，也许是系统日志，BUG管理系统等等。这也应该是在开发之前就定义好的。

程序员应该把异常抛给最上层，不能擅自作主。

逻辑设计人员应该以消灭异常为己任，在业务逻辑中明确描述每一个功能的进入条件（程序员可以使用断言），并且对每一个功能的后置条件表述很清楚（程序员可以使用断言）。