超人也害羞
2016-06-01 15:41
采纳率: 100%
浏览 1.2k
已采纳

java web mvc 错误异常

最近刚刚在一家小公司实习,自己一个人写一些小项目,ssh。最近在写代码的时候,很纠结该怎么处理异常,比如在dao中如果遇到了异常,是应该自己catch,坐相应的处理,还是应该 throw,让上层去处理他,甚至是直接丢给struts框架,然后在struts.xml 配置来catch这些异常。

  • 点赞
  • 写回答
  • 关注问题
  • 收藏
  • 邀请回答

3条回答 默认 最新

  • devmiao 2016-06-01 15:51
    已采纳
    点赞 打赏 评论
  • 毕小宝 2016-06-02 00:39

    一般的业务层代码如Service类中的异常,都是往上层控制层抛出,由控制层进行处理的。

    点赞 打赏 评论
  • 破小孩儿 2016-06-02 01:10

    这个话题要说的太多了。因为不仅是Java新手,很多老的Java程序员在Java异常处理上的习惯和观念都很不正确。
    我个人是比较赞同《Java编程思想》里关于异常的说明的,欢迎去翻阅和体会。
    我以一个典型的后台三层架构来简单描述一下我的经验:
    后台三层架构从外向内是:协议层(或者接口层,如生命Restful服务,spring mvc controller等),业务层,DAO层。

    • 我通常会在业务层设计两个异常:BussinessException, BussinessRuntimeException.
    • 如果业务层在处理过程中遇到任何**业务问题**,如实体找不到,验证不通过,实体冲突等,将问题以BussinessException异常的形式抛出。
    • 如果业务层在调用DAO或其他三方组件时,遇到不得不捕获的异常,首先要判断一下这些要捕获处理的异常是否是真的会发生。倘若认定不可能发生的异常,我们认定为是bug,将异常包装成BussinessRuntimeException抛出,如果是可能由业务问题而导致发生的异常,如同上一点,以BussinessException异常包装抛出。特别强调的是,bug类的异常是我们要在开发和测试的迭代工程重要消灭的,把bug包装成成BussinessRuntimeException抛出,不会为了给程序员提供不处理bug的便利,而是逼迫程序员要尽可能早地发现并修正bug,而这一点,常常在日志里出现RuntimeException类的异常堆栈是最显眼的,也不给上层感知到此时,从而避免故意捕获bug而作掩盖。
    • 准确的日志很重要,无论在抛出BussinessException还是BussinessRuntimeException时,都应该打印日志:对BussinessException打印warn级别日志,说明问题现象、原因等,且不用打印异常堆栈。对于BussinessRuntimeException打印error级别日志,且打印出堆栈。
    • 建议在创建BussinessException时,提供错误码以表示具体的业务问题。
    • 协议层对服务层的调用,一律要捕获BussinessException,并根据BussinessException携带的错误码,产生相应的响应,返回给前台。
    • 在整个框架上,需要有一个处理其他类异常的点,所有未捕获处理到的异常都会落入这个点来处理,比如BussinessRuntimeException,对于此类异常,需要有一个统一的报告机制:统一的前台提示和统一的日志打印。在这类异常发生时,需要及时关注并处理,因为这意味着bug

    这些大致说明了我的经验,还很粗。更详细的我制定在了我所在公司的产品编码规范里,就不方便了。你自己多做项目,积累经验,希望能找到自己觉得更合适的。

    点赞 打赏 评论

相关推荐 更多相似问题