由于Java Web应用业务逻辑的复杂性，很容易出现一些意想不到的错误和异常，给系统调试带来不必要的麻烦。 不友好的提示信息使程序员无法处理错误和异常。 尤其是发生异常时，Java异常栈输出的信息只能程序员查看，绝对不能显示给用户。 而一旦项目发布到最终版本并运行后，非常有必要跟踪记录发生的错误和异常的详细信息，并返回给用户特定的友好界面。 在传统的Java Web应用程序中，应用程序通常使用硬编码方法来防止即将出现的错误和异常。 应用程序中的异常通常使用 try...catch 语句进行处理。 可能抛出异常的地方，它们就在那里。 捕获一下，这些语句实际上成为了编译器对付的最后手段。 为了简化，catch代码块中往往什么都不写，try...catch语句就成为一种装饰。 甚至简单地使用关键字 throws 来声明抛出异常，并且不对异常进行处理。 这样不但会让写出来的程序变得杂乱无序，而且还充满了无用的try...catch语句。 它将大大增加程序的可读性和可修改性，同时也减少了程序员的工作量。
针对上述问题，考虑到JavaWeb应用的开发、未来运行、升级和维护，基于Java异常机制，建立了JavaWeb环境下错误处理和异常处理的框架模型。 该模型统一管理异常和错误网站程序异常，并在集中位置进行处理。 程序的可读性、可维护性、可修改性、健壮性等都得到了提高。 本文使用Struts、Spring和Hibernate构建一个三层Java Web应用程序。 Struts作为表示层，Spring作为业务逻辑层，Hibernate作为持久层。
2.1 错误与异常处理原则
本文的错误处理方法是抛出自定义类型的异常，这样可以更方便地统一管理异常和错误，提高Java Web应用程序的健壮性。 Java Web应用程序开发中产生的所有异常都应该继承Exception（属于checkedException类型）。 而且，Java Web应用程序通常采用三层或多层架构。 程序员不需要在每一层处理错误和异常。 应用程序中的每一层在打包和传递异常时都必须过滤掉Runtime-Exception。 从责任的角度看，Unchecked异常是程序的责任； 检查异常是特定应用程序的责任。 无论如何，我们不应该将像uncheckedException这样的异常暴露给客户，因为他们没有责任解决这个问题。 这些异常应该封装成checkedException类型的异常，由具体的应用程序来承担这个责任。
2.2 错误处理策略
程序中可能会出现很多错误，比如删除记录、插入记录、修改记录时出错，以及复杂的业务逻辑等。 当错误发生时，你应该如何处理？
传统的做法是使用编程方法来提高应用程序的健壮性。 当出现错误时，由程序控制以友好的信息提示用户或显示错误提示界面。 显然，这些处理方法的本质是减少程序中的代码量，以填补程序中的缺陷。 治标不治本，不能从根本上解决问题。
本文采用的错误处理策略是，当发生错误时，将错误和错误发生的页面封装成异常对象并抛出，然后将异常集中到统一的位置进行处理。 显然，使用这些错误处理方法的好处是，当运行的程序发生错误时，会抛出详细的异常对象，并根据发生的异常信息来决定重定向到不同的页面。 避免一些由于采用编程而被忽视的错误（由于代码大小减小而导致的错误）。
2.3 异常处理策略
程序中可能会出现很多异常，比如业务逻辑、指定文件未找到、类型转换失败等。当发生异常时，Web应用程序应该将异常以及异常发生时发生异常的页面封装成一个新的异常。异常对象并抛出，然后将异常集中到统一的位置进行处理。 显然，使用这些异常处理方法的好处是，不向用户解释Java中的异常堆栈信息，而是向用户解释异常信息和友好页面。
使用异常来统一管理应用程序错误和异常的用处在于，因为Java的异常机制允许调用者不处理异常而使用关键字 throws 来抛出异常，这会导致异常被传递到下一级，即当当前环境没有足够的信息和能力来解决异常时，可以将异常交给一个更中间能力的环境，在那里对异常进行处理，并形成异常传递链。 这样所有的异常都可以通过这样一个传递链集中到一个统一的位置进行统一处理。
它使得错误代码显得更有条理，与硬编码的错误处理方式相比，代码量会显着减少，并且通过这些错误报告机制，错误只需要在一个地方处理，即在所谓“异常”，这种方法节省了代码，将描述要做什么的代码与描述出现问题时要做什么的代码分开。 简而言之，异常机制使得读取、写入和调试代码比使用硬编码方法处理错误更有组织性。
2.4 异常抛出策略及捕获位置
在图1所示的JavaWeb三层架构模型中，我们可以利用Java的多态机制，只捕获自定义子类异常（如BasicException），其中包含了所有应用程序异常的默认行为，但具体业务逻辑所抛出的异常可以可以是BasicEx-ception类的任意泛型异常，利用多态性隐藏该异常的具体实现类。 这意味着可以将 BasicException 异常（仅此异常）放置在引发已检查异常的每个方法的 throws 谓词中，并且不能包含任何其他应用程序异常。 当应用程序中发生特定的异常（BasicException的派生类）时，应用程序应该决定在哪个界面上显示哪个错误消息，即在哪里捕获该异常。 本文选择的位置是控制器（Struts的Action），它有能力根据不同的异常设置不同的错误信息并跳转到不同的错误页面，而Action的位置最接近客户端表现层。 所以这个位置是最合适的。
这样，所有异常都将在集中的公共位置进行处理。 使用模板方法（TemplateMethod）设计模式并与Struts的DispatchAction结合编译出模板方法，并捕获模板方法中的BasicException异常。 这将捕获所有常见异常。 异常型。 因此，我们采取的策略是：持久层所有方法都抛出BasicException，不处理； 业务逻辑层的所有方法都采用与持久层相同的策略，并且也不处理异常网站程序异常，即抛出BasicException。 异常。 利用这些通用机制来传播异常，并以通用形式将异常集中到距离客户端最近的控制器进行处理。 这种方法有很多优点：不需要将大量检查异常倒入 throws 谓词中； 你只需要在 throws 谓词中出现一个异常，并且不需要对应用程序异常使用令人困惑的 catch 块； 如果需要处理，一个catch块（BasicException就够了），程序员不需要自己进行异常处理（记录日志和获取错误码），让程序员可以更专注于业务逻辑、错误的处理异常情况可以通过以下方法进行处理和记录。 前面提到的Facade套接字已经完成。
3. 错误与异常处理模型实现
3.1 错误和异常层次结构
本文仅以两类错误和两类异常为例进行讨论。 然而，本文建立的错误和异常处理框架模型适用于任意数量的错误和异常类型，只要它们间接继承BasicException类，例如数据未找到类型错误。 例如 DataNot-FoundExceptionextendsBasicException。 逻辑异常：LogicaExceptionextendsBasicException 数据查找错误：DataExceptionextendsBasicException 权限异常：RightExceptionextendsBasicException 登录错误：LoginExceptionextendsBasicException 在实现具体工程项目时，可以根据需要减少错误和异常的类型。
3.2 应用与模型交互
该框架模型负责决定在 StrutsAction 层针对错误和异常采取什么操作。 此决定涉及识别引发异常的代码。 另外，您还需要知道处理错误和异常后，错误消息应该重定向到哪个接口。 我们需要根据异常类型来指定获取错误码的过程，并进行日志记录。 我们将这种工作形象化为一个socket，它基于外观设计模式，也称为Facade模式[10~11]。 该模式为子系统中的一组socket提供了统一的外部访问入口。
外观定义了一个更高级别的接口，使子系统更易于访问，并且是整个异常处理系统的外观，处理从 BasicException 派生的所有异常。 换句话说，这个socket是连接应用程序和框架模型的桥梁，为复杂的异常处理框架模型提供统一的操作店面。 采用这些设计模式的优点是：
它将异常框架模型子系统的复杂性与应用逻辑屏蔽开，使得异常框架模型系统更易于使用。 子系统和应用程序逻辑之间实现了松耦合关系，而子系统内的功能组件往往是紧耦合的。 方便为子系统添加新功能。 您只需要在Facade中添加一个新方法，然后用新函数调用该类或技术。 实际执行任务的原始类不需要更改。 如图2所示，给出了异常处理模型的时序图。
从图2可以看出，这些Facade模式的使用促使业务逻辑控制器只处理异常处理店面，简化了有关异常处理的业务逻辑的编程，使程序员更加专注于业务逻辑的编程。 如图3所示，给出了异常处理模型的时序图。
从图3可以看出，异常处理系统通过异常处理店面调用异常工具类，将所有可能的错误和异常封装成ExDTO对象返回给控制器，同时还将异常的详细信息记录在ExDTO对象中。日志文件。 有助于将来的调试和错误查找。
下面给出StrutsAction模式下异常处理的反例。
尝试{
/*
处理应用程序的业务逻辑
调用业务逻辑层的业务逻辑方法，该方法声明Ba-
异常情况
*/}
捕获（基本异常）{
//定义错误和异常处理程序
ExceptionHandlereh=newExceptionHandler();ExDTOexDto=eh.handleException(“context”,user,ex);ActionMessagesmessages=newActionMessages();messages.add(ActionMessages.GLOBALMESSAGE,newActionMessage(exDTO.getMessageCode()));
saveMessages(request,messages);//去用户那里有一个好的接口
返回映射。 findForward("errorAndExceptionOccur");}
3.3 精简Struts Action代码
从Action的编译方式可以看出，每个方法都必须编写捕获异常的模板代码，这种编码方式是应该杜绝的。 解决方案是利用Struts的DispatchAction的工作机制（该类的工作方法这里就不介绍了，可以查看帮助文档），结合模板方法模式（TemplateMethod）[10,11]重写template方法execute，并在execute方法中写入不变的错误和异常模板的代码，并将具体的变量business逻辑控制留给泛型。下面是定制的
StrutsDispatchAction中execute方法的具体实现示例。
尝试{
动作转发=
dispatchMethod(映射、表单、请求、响应、名称); 向前返回； }
//处理用户定义的错误和异常 catch(BaseAppExceptione){
//定义错误和异常处理程序
ExceptionHandlereh=newExceptionHandler();ExDTOexDto=eh.handleException(expDTO.getContext(),userId,e);
ActionMessagesmessages=newActionMessages();messages.add(ActionMessages.GLOBAL_MESSAGE,newActionMessage(exDTO.getMessageCode()));saveMessages(request,messages);//进入用户界面
返回映射。 findForward("errorAndExceptionOccur");}
// 处理非用户定义的错误和异常 catch(Exceptionex){
// 记录错误和异常
ExceptionUtil.logException(this.getClass(),ex,userId); throwex;
}最后
{exDisplay.set(null);}
经过这样的处理，Structs的每个Action只要继承DispatchAction类就可以手动继承错误和异常处理代码，节省了大量的代码编译。
4。结论
本文提出了一个关于错误处理和异常处理的框架模型，并借助三层架构实现了该模型，解决了Java Web应用中错误处理和异常处理的常见问题。 当应用程序出现错误和异常时，模型可以将错误和异常的详细信息记录到日志文件中，同时控制器可以根据这些信息将页面跳转到指定的网页。
由于本文重点讨论错误和异常处理模型，因此可以使用不同的工具来实现它。 例如，JSF和Struts2可用于表示层； Jdon可用于业务逻辑层； 持久层可以使用其他ORM框架，例如KylinORM、MyBatis等。
