NPE採用常規方法編譯時

我以奇怪的方式獲得NPE。其次是方法調用，因爲它的它的發生：NPE採用常規方法編譯時

String exec(String command) { 
     if (command == null || isConnected()) return null; 

     Session session = null; 
     boolean error = false; 
     try { 
      session = ssh.startSession(); 
//   try { 
//    final Session.Command cmd = session.exec(command); 
//    String result = cmd.getOutputAsString(); 
//    if (cmd.getExitStatus() != null && cmd.getExitStatus() != 0){ 
//     //TODO:command execution failure should be logged 
//     error = true; 
//    } else { 
//     return result; 
//    } 

//   } catch (Exception ex){ 
//    //TODO:command execution failure should be logged 
//    ex.printStackTrace(); 
//    error = true; 
//   } 
     } catch (Exception ex) { 
      // TODO:session creation failure should be logged 
      ex.printStackTrace(); 
      error = true; 
     } finally { 
      session.close(); 
      if (error) return null; 
     } 
    }

如果我取消了內部的try/catch塊（甚至聲明只）我得到常規產生的NPE如下：

java.lang.NullPointerException 
    at org.objectweb.asm.MethodWriter.visitMaxs(Unknown Source) 
    at org.objectweb.asm.MethodAdapter.visitMaxs(Unknown Source) 
    at org.codehaus.groovy.classgen.AsmClassGenerator.visitConstructorOrMethod(AsmClassGenerator.java:605) 
    at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitMethod(ClassCodeVisitorSupport.java:123) 
    at org.codehaus.groovy.classgen.AsmClassGenerator.visitMethod(AsmClassGenerator.java:696) 
    at org.codehaus.groovy.ast.ClassNode.visitContents(ClassNode.java:1039) 
    at org.codehaus.groovy.ast.ClassCodeVisitorSupport.visitClass(ClassCodeVisitorSupport.java:50) 
    at org.codehaus.groovy.classgen.AsmClassGenerator.visitClass(AsmClassGenerator.java:276) 
    at org.codehaus.groovy.control.CompilationUnit$12.call(CompilationUnit.java:748) 
    at org.codehaus.groovy.control.CompilationUnit.applyToPrimaryClassNodes(CompilationUnit.java:942) 
    at org.codehaus.groovy.control.CompilationUnit.doPhaseOperation(CompilationUnit.java:519) 
    at org.codehaus.groovy.control.CompilationUnit.processPhaseOperations(CompilationUnit.java:497) 
    at org.codehaus.groovy.control.CompilationUnit.compile(CompilationUnit.java:474) 
    at org.jetbrains.groovy.compiler.rt.GroovyCompilerWrapper.compile(GroovyCompilerWrapper.java:43) 
    at org.jetbrains.groovy.compiler.rt.GroovycRunner.main(GroovycRunner.java:128) 
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method) 
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:39) 
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:25) 
    at java.lang.reflect.Method.invoke(Method.java:597) 
    at com.intellij.rt.execution.CommandLineWrapper.main(CommandLineWrapper.java:75)

代碼沒什麼特別的，ssh變量不爲空。但我無法弄清楚到底發生了什麼。

來源

2011-03-31 Denys S.

您使用的是什麼版本的Groovy？ – 2011-03-31 14:22:58

你使用哪個SSH庫？ – 2011-03-31 14:28:23

@Emil，1.7.10; @tim_yates，請不要嘗試進入你實際上不需要的東西。 – 2011-03-31 15:37:46

它看起來像把如果（錯誤）返回null;出終於塊進入方法結束了伎倆，不完全確定爲什麼，但。

來源

2011-03-31 15:39:13

finally塊中的session.close（）會拋出一個NPE，因爲如果ssh.startSession（）失敗，會話永遠不會初始化。或者我錯過了聖？

來源

2011-03-31 14:29:45

是的，這不是問題。（這意味着它是潛在的問題，但不適合特定的代碼）請參閱我的答案。 – 2011-03-31 15:38:20

問題不在代碼中，而是隨着groovy編譯它的方式，所以最好的檢查地點是他們的bug跟蹤器http://jira.codehaus.org/browse/GROOVY。
您可以查找現有問題或創建一個問題。
這裏是一個簡化的例子，觸發errror，我不知道它是否可以變小，因爲我不知道確切的問題。

try { 
    try {} catch (e) {} 
} finally { 
    return anything 
}

我會說有嵌套try塊和明確的回報之間的相互作用。還要注意，這個塊必須是方法中的最後一個語句（如果用作腳本，它會拋出該NPE，這是run（）方法的最後一個語句）。

來源

2011-04-01 02:40:15 jpertino

NPE採用常規方法編譯時

回答

相關問題