Warning: file_get_contents(/data/phpspider/zhask/data//catemap/9/java/396.json): failed to open stream: No such file or directory in /data/phpspider/zhask/libs/function.php on line 167

Warning: Invalid argument supplied for foreach() in /data/phpspider/zhask/libs/tag.function.php on line 1116

Notice: Undefined index: in /data/phpspider/zhask/libs/function.php on line 180

Warning: array_chunk() expects parameter 1 to be array, null given in /data/phpspider/zhask/libs/function.php on line 181
理解JAVA中的throw关键字_Java_Exception_Exception Handling_Throw - Fatal编程技术网

理解JAVA中的throw关键字

理解JAVA中的throw关键字,java,exception,exception-handling,throw,Java,Exception,Exception Handling,Throw,在JAVA中进行异常处理练习时,我对各种事情感到有点困惑。基本上我不理解的是当遇到异常时程序的流程是如何的。我想了解在下面的场景中,程序的实际流程是如何发生的,以及我对这些概念的理解是正确的还是错误的 public void myFunction(){ try{ //Some code...... }catch(Exception e1){ //If this Exception is occured handl

在JAVA中进行异常处理练习时,我对各种事情感到有点困惑。基本上我不理解的是当遇到异常时程序的流程是如何的。我想了解在下面的场景中,程序的实际流程是如何发生的,以及我对这些概念的理解是正确的还是错误的

 public void myFunction(){

     try{

            //Some code......

        }catch(Exception e1){

            //If this Exception is occured handle it here.

        }catch(Exception e2){

           //if this exception has occured then

          throw new myException("whatever message required");
        }

       finally{

           //code that has to be executed 
       }

 }
现在我的理解是:

1.如果没有发生异常,那么代码将平稳运行,最终执行finally块中的代码 2.若异常e1发生,则在第一个catch块中捕获它,并在该块中进行适当处理,然后执行最后一个块。 3.但如果发生异常e2会发生什么情况。在catch块中,我们抛出一个新的异常。 所以我调用myFunction的方法应该提供一些机制来处理这个问题 我的异常?所以执行将转移到调用方法的catch块,对吗? 那么myFunction()的“finally”块会发生什么情况呢?那就不执行了? 程序流程是如何发生的?我真的很难发现当我们使用“扔”时会发生什么。当我们使用它时,会发生什么情况?

“调用myFunction的方法应该提供一些机制来处理此myException?” 应该是这样的,但是编译器只有在myException扩展了checked异常时才会让您这样做。
无论发生什么,最终块都将被执行

本质上,当遇到异常时,程序流停止,控制权向上转移到调用堆栈,直到异常被
try/catch
捕获,或者直到异常到达堆栈底部,此时线程终止

换句话说,“发生了什么,停止你正在做的任何事情,转到与此异常匹配的最近的catch块,除非不存在catch块,在这种情况下杀死线程”

在您的情况下,
e2
将永远不会发生,因为所有异常都已被第一个
catch
块捕获。如果要以不同方式处理不同的异常,通常会使用多个
catch
块,例如,如果要解析文件中的数字,则在一个块中使用catch
IOException
,在另一个块中使用
NumberFormatException

您不必处理运行时异常(扩展
RuntimeException
的异常)。您必须显式地处理选中的异常(扩展
Exception
但不扩展
RuntimeException
的异常)

无论是否引发异常,
finally
块中的代码都将被执行。

请参见(您修改的示例):

执行可能性:

 1. No exception at all:
   Some code executed
   Some final code executed
 2. SomeException is thrown:
   Some code (may be partially) executed  
   SomeException code executed
   Some final code executed
 3. SomeOtherException is thrown:
   Some code (may be partially) executed
   Some final code executed
   throw new myException("whatever message required");
 4. SomeStrangeException is thrown 
   Some code (may be partially) executed 
   Some final code executed
   System'll look for other try {} catch {} block to catch SomeStrangeException 

考虑以下示例(基本上,您的示例中只填充了一些实际代码,它旨在引发NullPointerException):

其输出为:

Finally Block
java.lang.RuntimeException: Exactly what we want happened
    at Exceptions.myMethod(Exceptions.java:14)
    at Exceptions.main(Exceptions.java:23)

您可以看到,finally块是在新的RuntimeException被传递给调用方法之前执行的。否则,“最终块”输出将在RuntimeException的stacktrace之后。

看:e1和e2都属于同一类型:Exception,这就是为什么catch(Exception e2)没有机会执行的原因。因此,如果抛出了一个在后续catch块中未处理的异常,首先执行finally块,然后如果异常是否在任何地方处理,程序只搜索调用堆栈?@neerajDorle:是的,这是一种非常方便的行为:首先清除资源,然后尝试(可能是徒劳的)修改原因(未捕获的异常)因此,如果抛出了一个未在后续catch块中处理的异常,则首先执行finally块,然后如果异常在任何地方处理或未处理,则仅程序搜索调用堆栈?是,尝试调试您的示例以了解流程如何进行请查看第一个答案中编写的修改代码并给出相应的答案。。。。。还有一个问题:如果抛出了一个在后续catch块中没有处理的异常,那么首先执行finally块,然后只有程序在调用堆栈中搜索是否处理了异常?我相信是这样的。最后,
块在JVM开始向上运行调用堆栈之前执行。没问题。很高兴我能帮忙
public class Exceptions {

    public static void myMethod() {
        try{
            String s = null;
            s.length();
        }
        catch(NumberFormatException e1){
            System.out.println("Something unexpected happend");
        }
        catch(NullPointerException e2){
            throw new RuntimeException("Exactly what we want happened");
        }
        finally{
            System.out.println("Finally Block");
        }
    }

    public static void main(String[] args){
        try{
            myMethod();
        }
        catch(RuntimeException e){
            e.printStackTrace();
        }
    }
}
Finally Block
java.lang.RuntimeException: Exactly what we want happened
    at Exceptions.myMethod(Exceptions.java:14)
    at Exceptions.main(Exceptions.java:23)