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

[baofengyingyinaaa]

大家一般怎么处理项目中的异常
(代码上的异常处理)

我是这样的，
向上抛，让上一层解决。
写日志，记录。跳转到错误页。
或者在该类解决。

希望大家给我点意见。

[hhcwd]

学习了

[gaokangstudy]

学习了

[reanfan]

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

[longlikema]

[Quote=引用 11 楼 reanfan 的回复:]
1.底层将强制异常转化为非强制异常
2.定制的非强制异常类有能接受 thrown的构造器,并且有明前的分类作用
3.上层中根据这些分类 采用不同的异常处理机制
[/Quote]

没错，我们就是这样做的

[yymn_love]

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

[libo_java]

如果是大型项目 我建议楼主进行自定义异常，当出现异常的时候抛出自定义的异常号，以此类推，最终在基类中对所有自定义异常进行捕获，根据传过来的异常编号做相应的异常处理，这种做法比较通用。

[chan10]

往上抛，留给具体程序，来定义错误信息。

[mf0606]

抛出异常最简单，嘿嘿！

[marf_cn]

一般都是在本类中解决，方便错误定位。

[keeya0416]

最好是那出就那解决
别把自己的事交给别人去做
生活中也是一样的道理

[to_heaven]

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

[yueguangkai001]

我看到有的是在异常处理中做事,如果出现异常,程序又改怎么去进行,抛出去作用也不大,也影响程序的运行

还有就是抛出错误,就是跟LZ的差不多的想法,

[java_zhengjd]

一般不要向上抛，一个工程项目中异常的解决很重要，要考虑周到，尽量扑获处理。

[Dan1980]

具体问题具体分析。

不过，一个基本的原则是，“如果你没有100%的把握能妥当地处理异常，最好是把它抛出去，交给上级处理”。因为越是上层的代码，越是统筹全局的，统筹全局的更清楚应该怎么处理全局性的异常。

2楼说生活中的例子，其实应该这么说，自己搞得定的事情自己搞定，自己搞不定还一定要去搞定，那叫逞能，最后连累的不仅仅是自己。

比如，系统有一个统一的错误信息提示处理机制，它负责捕获所有最终的异常并决定如何（或是否）显示给用户。你在编写一个读文件的方法时，把IO异常非常简单地处理掉了（很多人通常是catch后面跟一对花括弧就完事），结果文件没有读出来，而错误信息也没有正确地传达给最终用户。

所以，6楼说的恰恰反掉了，随随便便就把异常处理掉，而不抛出的话，那才是真正导致“具体那一块出的问题查不出来了”的原因。

在大的工程里，一个public类的public方法该不该声明抛出异常，是应该在早期就设计好了的，不会留到编码阶段由程序员来决定。如果你负责编写的某个方法设计为抛出某种类型的异常，那么你遇到异常时一定要抛出，而不要自己处理。

[hardycheng]

还是在出问题的地方处理

尽量不要 往上一层抛，那样的上一层又往上上一层抛，

到后来你只能知道出异常了，但是具体那一块出的问题查不出来了。

[to_heaven]

尽量不要 往上一层抛，那样的上一层又往上上一层抛?
这点是不同意的。

首先要规划下项目中要处理的异常有哪些，业务的异常应该是要在程序中处理，并转化为文字显示给用户查看的。 非业务的异常看是否影响程序执行结果，如是直接返回异常消息，并中止此次操作，否现Log下就可以了。

可以用ExceptionManager将Exception转换为Error, 这样就不用在所有方法中都写throw Exception了。

[luozhangwen]

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

[baofengyingyinaaa]

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