2012-03-28 9 views
4

Hier ist die seltsame Ausnahme, die ich mit dem entsprechenden Code bin immer unten verwiesen:NPE beim Zugriff auf einen primitiven Typ (double) des instanziierten und vom Konstruktor konfigurierten unveränderlichen Objekts. (Kein Autoboxing oder Reflexion beteiligt ist)

23:51:39 bei java.lang.Thread.run (Unknown Source)
23.51 : 39 at java.util.concurrent.ThreadPoolExecutor $ Worker.run (Unbekannte Quelle)
23:51:39 bei java.util.concurrent.ThreadPoolExecutor $ Worker.runTask (unbekannte Quelle)
23:51:39 bei com .dk.actions.c.run (Unbekannte Quelle)
23:51:39 bei com.dk.actions.TesterAction.yw (Unbekannte Quelle)
23:51:39 bei com.dk.actions .TesterAction.yX (Unbekannte Quelle)
23:51:39 unter com.dk.agent.tester.b.Bc (Unbekannte Quelle)
23:51:39 unter com.dk.agent.tester.r.run (Unknown Source)
23.51.39 bei com.dk.agent.tester.ba (Unknown Source)
23.51.39 bei scal.Scal.onBar (Scal.java:241)
23.51 : 39 at scal.Supres.evalSupres (Scal.java:2678)
23:51:39 bei scal.SR.supp (Scal.java:2187)
23:51:39 bei scal.SR.evaluateSRfor (Scal .java: 2361)
23:51:39 bei scal.SR.isAtSR (Scal.java:2385)
23:51:39 bei scal.SR $ Con.access $ 5 (Scal.java:1741)
23.51.39 java.lang.NullPointerException

Oh, bevor Sie fragen, ja, alle Klassen dieser App sind in einer Datei. Frag nicht warum. Ist einfach so. Im Folgenden sind die Referenzen mit Code auf den obigen Stack-Trace:

ref. scal.Scal.onBar(Scal.java:241): 
     try{ 
     for(Ins instr : supresSourceMap.keySet()) 
      for(Per p : supresSourceMap.get(instr).keySet()) 
    241:  supresSourceMap.get(instr).get(p).evalSupres(currTime); 
      } catch (Exception e){ 
       e.printStackTrace(console.getErr()); 
      } 
ref. scal.Supres.evalSupres(Scal.java:2678): 
    public void evalSupres(long time) throws Exception{ 
     ... 
    2678: sup.supp(Con.of(getIns(), getPer(), center, time, conRange, true), null); 
     ... 
    } 
ref. scal.SR.supp(Scal.java:2187): 
    void supp(Con nHt, Con remove){ 
     ... 
    2187 evaluateSRfor(nHt); 
     ... 
    } 
ref. scal.SR.evaluateSRfor(Scal.java:2361): 
    private void evaluateSRfor(Con nHt) { 
     if(!hits.get(nHt.per).isEmpty()){ 
      Con lastHt = getLastHt(nHt.per); 
      if(lastHt != null){ 
       if(lastHt.srSource == null){ 
        if(isNewSR(nHt)){ 
         addNewSR(nHt); 
        } 
       }else{ 
    2361:   if(isAtSR(nHt)){ 
         addConToLastSR(nHt); 
        } 

       } 

      } 
     } 
    } 
ref. scal.SR.isAtSR(Scal.java:2385): 
      private boolean isAtSR(Con nHt) { 
       ... 
    2385:  double high = nHt.getHighestCon().upperConBound; 
       ... 
      } 
     ref. nHt.getHighestCon() : 
      Con getHighestCon(){ 
       Con highCon = null; 
       boolean contains = false; 
       if(this.srSource != null){ 
        highCon = srSource.getFirst(); 
        for(Con con : srSource){ 
         if(!contains) 
          contains = this.equals(con); 
         if (con.compareTo(highCon) > 0) { 
          highCon = con; 
         } 
        } 
       if(!contains) throw new IllegalStateException("getHighestCon(): " + this.toString() + " does not belong to its srSource list: " + srSource.toString()); 
       } 
       return highCon; 
      } 
ref. scal.SR$Con.access$5(Scal.java:1741): 
    1741: private final double upperConBound; 

Wichtige Hinweise:

  • srSource ist ein Feld in der Con-Klasse von LinkedList <> Typ.
  • Die Methode getHighestCon() wird im Con-Typ definiert.
  • Der Typ Con ist eine statische innere Klasse innerhalb des Typs SR.
  • Der Con-Typ ist unveränderlich, obwohl die SrSource-Liste nicht endgültig ist und instanziiert und später von einer Setter-Methode aufgefüllt wird.
  • Jede Con-Instanz enthält einen Verweis auf sich selbst innerhalb der SrSource-Liste.
  • Ich habe den Con-Typ mit hashCode(), equals(), toString(), Comparable (compareTo (Conf c)) implementiert. Keiner von ihnen verwendet das Feld SrSource in seinen Berechnungen.
  • Feld "private final Doppel upperConBound" von Konstruktors von Con über statische Methode initialisiert:
    • this.upperConBound = Wert + Utils.pValue (INS, conRange);
  • Das Problem verschwindet nicht, wenn ich über Methode statt direkt auf das Feld zugreifen.
  • verschwindet jedoch das Problem, wenn ich das upperConBound Feld Zugriff von isAtSR() wie folgt aus:
    • Doppel hoch = getHighestCon (srSource) .upperConfBound;
  • Wo:
    • srSource ein Feld von SR-Instanz und
    • das Verfahren getHighestCon (LinkedList <> srSource) in dem SR-Typ in der gleichen Art und Weise durchgeführt wird, wie es in Con-Typ ist, aber Zugriff auf den Parameter anstelle eines Felds und keine Ausnahme auszulösen.
    • Bedenken Sie, dass die obige Lösung nicht die Lösung ist, nach der ich suche. Ich brauche die Methode getHighestCon(), die innerhalb des Con-Typs implementiert wird und funktioniert. Wenn Sie Fragen haben oder weitere Codebeispiele benötigen, lassen Sie es mich wissen. Ich schätze deine Zeit, die ich damit verbracht habe, das für mich zu lösen.
+2

Aaaah, zu viel Code. Bitte koche dies auf einen [** minimalen ** Testfall] (http://sscce.org). –

+0

Können Sie die Ausnahme mit kleinerem Code reproduzieren? Könnten Sie es auf nur 10-15 Zeilen herunterkochen, die das Problem aufzeigen? – sarnold

+0

Was ist die JVM? Ist es Sonne oder eine benutzerdefinierte wie JRocket? –

Antwort

0

Feld "private final Doppel upperConBound" von Konstruktor von Con über statische Methode

Java initializer Reihenfolge innerhalb des Quellcodes Klasse initialisiert ist sehr wichtig. Versuchen Sie, sowohl die Obere Converting-Felddeklaration als auch den Statischen Initialisierer vor allem anderen innerhalb des Con-Klassenquellcodes zu platzieren.