java 异常处理问题。谢谢大家了

Question

大家一般怎么处理项目中的异常
(代码上的异常处理)我是这样的，
    向上抛，让上一层解决。
    写日志，记录。跳转到错误页。
   或者在该类解决。希望大家给我点意见。

Answer 1

建议使用ExceptionManager统一处理。 ExceptionManager.handle(Exception ex)。 

Answer 2

尽量不要 往上一层抛，那样的上一层又往上上一层抛? 
这点是不同意的。首先要规划下项目中要处理的异常有哪些，业务的异常应该是要在程序中处理，并转化为文字显示给用户查看的。 非业务的异常看是否影响程序执行结果，如是直接返回异常消息，并中止此次操作，否现Log下就可以了。可以用ExceptionManager将Exception转换为Error, 这样就不用在所有方法中都写throw Exception了。

Answer 3

日志在最底层打,然后往上面抛,  一直抛到Action在try catch 获取异常code

Answer 4

1.底层将强制异常转化为非强制异常
2.定制的非强制异常类有能接受 thrown的构造器,并且有明前的分类作用
3.上层中根据这些分类 采用不同的异常处理机制

Answer 5

今天刚学的异常。老师给我们介绍的是先throws ，因为当时可能不知道处理异常后给出什么提示信息。到一个不会再被调用的并且引发了那个异常的方法里面去做处理

Answer 6

具体问题具体分析。不过，一个基本的原则是，“如果你没有100%的把握能妥当地处理异常，最好是把它抛出去，交给上级处理”。因为越是上层的代码，越是统筹全局的，统筹全局的更清楚应该怎么处理全局性的异常。2楼说生活中的例子，其实应该这么说，自己搞得定的事情自己搞定，自己搞不定还一定要去搞定，那叫逞能，最后连累的不仅仅是自己。比如，系统有一个统一的错误信息提示处理机制，它负责捕获所有最终的异常并决定如何（或是否）显示给用户。你在编写一个读文件的方法时，把IO异常非常简单地处理掉了（很多人通常是catch后面跟一对花括弧就完事），结果文件没有读出来，而错误信息也没有正确地传达给最终用户。所以，6楼说的恰恰反掉了，随随便便就把异常处理掉，而不抛出的话，那才是真正导致“具体那一块出的问题查不出来了”的原因。在大的工程里，一个public类的public方法该不该声明抛出异常，是应该在早期就设计好了的，不会留到编码阶段由程序员来决定。如果你负责编写的某个方法设计为抛出某种类型的异常，那么你遇到异常时一定要抛出，而不要自己处理。

Answer 7

public class ProductException extends Exception {
/** 
 * @param: 异常信息
 * @Description: 构造方法
 * ${tags} 
 */
public ProductException(String msg) {
super(msg);
}
}
这样写可以吗？没有几年经验，真搞不定。