错误屏障的下一个职责是以受控方式停止操作。这个职责的含义由应用程序的设计决定，但是通常会涉及到为等待响应的客户端发出总体响应。如果应用 程序是Web service，这意味着使用soap：Server的<faultcode>和普通<faultstring>失败消息将 SOAP <fault>元素嵌入到响应中。如果应用程序与Web浏览器进行通信，屏障将安排发送普通的HTML响应，表示无法处理此请求。</fault></faultstring></faultcode>

　　在Struts应用程序中，错误屏障采用全局异常处理程序的形式，配置成可以处理RuntimeException的任何子类。错误屏障类将扩 展org.apache.struts.action.ExceptionHandler，在需要实现自定义处理时重写方法。这将处理由于疏忽产生的错误 条件和处理Struts操作中明显发现的错误条件。图2显示了意外事件异常和错误异常。

图2 意外事件异常和错误异常

　　如果开发人员正在使用Spring MVC框架，简单地扩展SimpleMappingExceptionResolver并进行配置使其能处理RuntimeExceptio及其子类，便 能建立起错误屏障。通过重写resolveException()方法，在使用超类方法向发送普通错误显示的查看组件发出请求之前，开发人员可以添加任何 自定义处理。

　　当架构包含错误屏障并且开发人员也意识到了它的存在时，编写一劳永逸的错误异常处理代码的吸引力急剧下降。结果是在应用程序中产生更简洁和更易维护的代码。

　　架构中的意外事件处理

　　随着错误处理委托给屏障，主要组件之间的意外事件通信变得更加简单。意外事件代表了另一种方法结果，此结果与主要返回结果同样重要。因此，已检 查异常类型是传递意外事件条件存在性并提供对付异常条件所需信息的良好工具。最佳实践是借助Java编译器来提醒开发人员他们正在使用API的所有方面， 同样需要提供方法结果的全部范围。

　　通过单独使用方法的返回类型，可以传递简单的意外事件。例如，返回null引用而非实际对象可以说明此对象由于明确的原因而无法创建。Java I/O方法通常返回整数值-1，而不是字节值或字节计数，用来表明文件的结束。如果方法的语义非常简单允许这样做，另一种返回值可以使用这种方式，因为它 们消除了由异常而带来的开销。不利方面是方法调用者负责检测返回值，来查看它是主要结果还是意外事件结果。然而，编译器并不强制调用者做这样的测试。

　　如果方法具有void返回类型，异常将是表明意外事件发生的唯一方法。如果方法返回对象引用，则返回值所表达的意思仅限于两个值（null和 non-null）。如果方法返回整数值，通过选择确保与主要返回值不相冲冲突的值，就可以表达数个意外事件条件。但是现在已经进入了错误代码检查的范 畴，这是Java异常模型需要避免的情况。