try catchネスト実行順序テスト

テストtry catchの実行順序とコードの後続の実行を共有すると、実行されないコード:

 @Test
    public void testTryCatch(){
        try {
            System.out.println("   try ！" );
            //Integer.parseInt(null);
            try {
                System.out.println("   try    try " );
                Integer.parseInt(null);
            }
            catch (Exception ex2) {
                Integer.parseInt(null);
                System.out.println("   try    catch " );
            }
            finally {
                Integer.parseInt(null);
                System.out.println("   try    finally");
            }
            System.out.println("  try  ！");
            Integer.parseInt(null);
        }
        catch (Exception ex) {
            try {
                System.out.println("   try " );
                Integer.parseInt(null);
            }
            catch (Exception ex2) {
                System.out.println("   catch " );
            }
            finally {
                System.out.println("   finally");
            }
            System.out.println("  catch " );
        }
        finally {
            System.out.println("  finally！");
        }
    }

コメントでInteger.parseInt(null); 自分が異常を走りたいポイントをクリアし、その後の処理の順番を見ます.
まとめ:異常な点を投げ出して、後続のコードは実行しないで、それから最近のcatchを探して、catchとfinallyを実行して、それから外層に実行します.
しかし、catch内部に再び異常が発生すると、最近のcatchが見つかるまで外層に放出されます.ネストされたtrycatchを使用するときに注意しなければならないのは、異常、異常の順序がどこに投げ出され、その後は実行されない可能性があるかということです.
springのコードをもう1段共有します

if (this.registrar.hasTasks() && this.registrar.getScheduler() == null) {
    Assert.state(this.beanFactory != null, "BeanFactory must be set to find scheduler by type");
    try {
        // Search for TaskScheduler bean...
        this.registrar.setTaskScheduler(this.beanFactory.getBean(TaskScheduler.class));
    }
    catch (NoSuchBeanDefinitionException ex) {
        logger.debug("Could not find default TaskScheduler bean", ex);
        // Search for ScheduledExecutorService bean next...
        try {
            this.registrar.setScheduler(this.beanFactory.getBean(ScheduledExecutorService.class));
        }
        catch (NoSuchBeanDefinitionException ex2) {
            logger.debug("Could not find default ScheduledExecutorService bean", ex);
            // Giving up -> falling back to default scheduler within the registrar...
        }
    }
}

最後に個人的な観点を述べ,ネストされた異常処理作業をできるだけ避ける.論理が簡単でない限り、一定の可読性がある場合、可読性に大きな影響を及ぼし、また、後続の処理論理異常を避けることができます.