J2EE项目异常处理

如果我用别人的API
他有unchecked Exception但是我想捕获
也可以捕获。。。之后包装成checked再抛出就可以了。

我认为unchecked出现可能是由于程序问题才产生的。。。
而check的出现是由于业务逻辑上，
人为可能会进入系统的错误。
不必由程序员来解决的问题都用check来作处理

写代码时要注意一下这样的
方法名 （参数，参数）{
如果参数错误用checked异常
try{
代码簖
}check(){
如果这里出了连接异常就出checked异常

}check(){
如果这里出了其它异常就出uncheck异常
}finalyy{}

捕获unchecked再包装成checked，有着必要吗？
上层直接捕获unchecked处理不就得了。

所以对于使用un checked的异常，它的API一定需要在JAVA DOC中说明清楚。这个异常在什么情况下会抛出。
反过来也说，在使用一个会抛出异常的方法时，需要去查看它的API文档。异常将会在什么情况下抛出。

当然是有必要的！！
比如说，调用EJB,会抛出remote Exception!!

如果我们直接处理
methodA()
try{

  //ejb调用
}catch(RemoteException ex){

    //这里怎么处理比较合适呢？
}

一般的方式是转为业务系统的异常，相当于继续往上抛出。
methodA() throws BusinessException
try{
   //ejb调用
}catch(RemoteException ex){
  throw enw BusinessException(ex);
}
这里BusinessException是checked 异常。这相当于我自己处理不了，但是由上一层调用者去处理。
当然一般情况下，这样已经够了。可以避免了业务系统被深度的侵入。又不丢失异常信息。

但是像RemoteException这样的异常是非常严重的异常。一般是无法恢复的。所以转为unchecked异常后再处理会更好一点
methodA()throws RuntimeException
try{
  //ejb调用
}catch(RemoteException ex){
  throw new RuntimeException(ex);
}

这样，上层调用者就已经解脱了，而又没有丢失原本的异常的详细信息。

当然，我这里只是为了说明异常处理。并不是指EJB调用这样处理异常就够了。

因存在方法嵌套，通常JAVA DOC对unchecked Exception无法定义的非常详细。
反过来想一下，绝大多数状况我们会处理unchecked Exception吗？不会的，log以下而已，因此我的建议是当你需要对异常进行特殊处理时再去查JAVA DOC，这时候也来的及，其他情况交给异常框架处理吧。

但是也不竟然！！！
许多的RuntimeException是需要捕获的！！！！
我的文章已经说清楚了！！！

往往来说,unchecked 异常一般都会在系统的底层。
checked异常一般为业务异常！！！

审题要清楚哦，我说的是

java doc一般是会标出该方法会抛出什么异常。但是通常不会标出，在什么情况下会抛出该异常。
如果是一个基础性的代码，我个人的观点是需要标示在什么情况下会抛出该unchecked异常。

大多数情况下，我们是无需要处理unchecked 异常！！！！
但是有时我们必须处理unchecked异常！！！特别是越接近客户端的地方。这样才能给用户一个友好而坚固的系统。
比如用户从页面录入了一个日期，在controller或action中把日期字符转成Date类型时,
SimpleDateFormat.parse方法抛出的是unchecked异常！！！
但是用户录入错误是应该让用户重新录入的，并提示用户。

如果你不进行处理，可能就会直接报一个异常到页面！！！
这是用户最不期望的！！！！

sorry!!!是我看错了吧！！！
如果你捕获unchecked异常就说明你能够去处理他。
如果你捕获unchecked异常，又没有能力去处理他。而是封装成一个checked异常抛出。得不偿失

是呀，需不需要处理是业务逻辑的事情，该处理就去处理摆，这和使用什么类型异常没关系。
说到方法嵌套这涉及到一个父类接口签名的问题，checked exception对此支持不是很好。