本帖最后由 ayds1984 于 2009-12-05 19:38:06 编辑

解决方案 »

  1.   

    我觉得runtimeException应该用程序尽量避免,而不是抛出来
      

  2.   

    checked异常一般是业务性的异常,程序运行在预料之中的异常(比如说用户密码错误异常,那是意料之中的事情),此类异常一般都要求申明抛出,上层必须能处理此类业务异常。runtime异常一般是由程序编写的本身错误引起的,一般不需要处理,配置出错页面就好了
      

  3.   

    我碰到过反而是不抛出详细的异常信息的比如在内部catch到了异常之后,直接抛出一NullPointerException,搞得我错误都没法跟踪。。
    如果公司定义了比较好的异常结构,Code、Message足够详尽,让你在coding的时候能够根据他们定义的找出你代码的错误,我想还是可以接受的。原来做过一华为外包项目,他们的规定就是不得抛出java里面的异常信息,所有异常都要在代码里面定义code和message,而业务逻辑的Action直接把这些message扔过去,页面直接显示。这样就不会把一些未知的或者客户读不懂的消息抛出去,更加人性化。而底层的异常,有维护人员从db和log文件中来定位错误。
      

  4.   

    呵呵,个人的一点愚见:
    我个人写程序的时候,我希望所有的错误都可以在编译阶段被发现,也就是在程序运行之前就可以排斥所有的错误,但是,呵呵,这个好像不现实,因为有些问题必须在运行期间解决。在我所学习的语言中,我好像只见到过java语言提供了Checked异常,Java认为Checked异常都是可以被处理(修复)的异常,所以java程序必须显示处理Checked异常,我觉得这个Checked异常是很帅的,虽然有点小麻烦。它确实增加了代码的复杂度以及降低了程序的开发效率,不过有了Checked之后,觉得java程序更加严谨和健壮。
      

  5.   

    关于异常,如果能处理就处理而不要选择抛出,真正不能处理,抛给你上级runtimeexcption是程序本身错误导致。应该写代码的时候 就要避免