0

我有以下代码：

 method1() throws Exception{
 //throws an Exception
 }

 method2() throws Exception{
    method1();
    //do something
 }

 method3() throws Exception{
     method2();
     //do something
 }

 method4() throws Exception{
   try{
       method3();
       //do something
    }catch(Exception e){
       //catch exception
     } 
  }

如果在 method1() 中发生异常，它会冒泡到 method4() 并在那里被捕获。

但是，我在一些与此类似的问题的答案中发现，其中异常以以下方式引发：

 method1() throws Exception{
   //throws an Exception
 }

 method2() throws Exception{
    try{
       method1();
    }catch(Exception e){
        throw e;
    }
  }

重新抛出异常的最佳方法是什么？为什么更好？

在我阅读的有关“异常处理”最佳实践的文章中，他们说要早扔，晚抓。这是否意味着我们必须从内部方法中尽可能地重新抛出异常？

如果我的 method1() 抛出 SQLException，我应该只在 method4() 中捕获它还是在 method1() 本身中处理它？

更新： 比如说，如果方法 1() 中发生异常，我想在 UI 中显示一些消息。那么解决方案是什么？我应该把它冒泡还是返回一个表明问题的值？

method4() 将向 UI 显示一些消息。

4

1 回答 1

1

只是抛出异常throw e;对我来说似乎不合理。如果throw您声明了一个自己的异常类，该类封装了一组基本异常，请使用。或者使用它，如果您的程序检测到无效（业务）数据，这本身不会导致异常。

此外，我会尝试减少throw方法中的声明数量。最好使代码对任何类型的异常都更加健壮，而不是拥有大量异常和try catch块。一直明确地冒泡一个异常（使用throw）会使程序更长且可读性更低。

尽可能尝试处理异常；例如，如果用户试图打开一个不存在的文件，显示一个警告并返回一个值，这表明父进程失败了。

Throw early的意思是：你的方法应该尽早验证输入数据并抛出运行时异常，如果有什么不符合规定的话。赶上迟到至少意味着：避免捕捉异常，如果你对此无能为力的话。让他们宁愿冒泡并记录他们或通知用户（取决于系统）

Exception检查和之间的区别RuntimeException。

于 2013-03-07T22:27:22.417 回答