2017-07-19 6 views
2

Überprüfung Ich habe das folgende Stück von Java-Code:Wie Eclipse-(Java) konfigurieren benutzerdefinierte Behauptung zu erkennen, wenn gegen mögliche Nullzeiger

public void silence(final Object key) { 
    final Chain chain = (Chain)getChain(key); 
    checkPrecondition(chain != null); 
    chain.silence(); 
    } 

Der checkPrecondition Aufruf wirft eine Laufzeitausnahme, wenn Kette null ist, aber von Eclipse scheint nicht zu "bekommen": es sagt chain.silence() ist ein möglicher Nullzeigerzugriff (Warnung). Frage: Wie kann ich Eclipse "sagen", dass checkPrecondition() sicherstellt, dass die Kette nicht null ist, d. H. Den Charakter einer Assertion hat? Ich weiß, dass ich diese Warnung deaktivieren kann, aber das möchte ich lieber nicht tun, da dies in anderen Situationen gerechtfertigt sein könnte.

Interessanterweise verschwindet die Warnung, wenn ich den Aufruf checkPrecondition() entferne (was genau der Fall ist, in dem ich es erwarten würde).

Ich verwende Eclipse 4.4.2 (32 Bit) unter Windows. Java VM ist 1.3 (!). Das Update auf neuere Versionen von beiden ist derzeit keine Option.

+0

Unzusammenhängend: da Sie sich Gedanken über die Code-Qualität machen ... überlegen Sie, ob Sie wirklich diesem hässlichen Ansatz folgen wollen, überall "final" zu setzen. Wenn die Kette final ist, wird dieser Methode der Wert * null * hinzugefügt. Es ist nur Linienrauschen, das keinem wirklichen Zweck dient. – GhostCat

+0

In diesem Fall hat die Verwendung von "final" zwar begrenzten Nutzen, aber auch keine Kosten. Also kein Verlust insgesamt. In anderen Zusammenhängen kommuniziert die Verwendung von "final" die Absicht des Programmierers und kann verursachen, dass Codierungsfehler zum Zeitpunkt der Kompilierung und nicht durch langwierige Tests erkannt werden. Unsere Kodierungsrichtlinie fordert explizit die Verwendung von "final", und das gilt auch für die meisten modernen und ernsthaften Kodierungsrichtlinien, die ich gesehen habe. Sehr hoher Nutzen! – FreeSpirit64

+0

Und deshalb investierten die Java-Leute wertvolle Zeit in die Verbesserung des Compilers, um ** effektiv ** finale Variablen zu erkennen - damit Sie für lokale Variablen, die sich danach nicht ändern, nicht endgültig schreiben müssen ;-). .. und wie du mich neugierig gemacht hast: Kannst du ein paar Beispiellinks geben? – GhostCat

Antwort

0

Sie sagen nicht zu Eclipse, Sie müssen einen Code in einer solchen Syntax und Logik erstellen, dass der Java-Compiler erfolgreich kompiliert wird und dass die JVM ausgeführt werden kann.

Es ist normal, dass eine Laufzeitausnahme auftritt. Ein Variablenwert kann nur zur Laufzeit überprüft werden, genauso wie der Nullzeiger (tatsächlich ist es in fast jeder Sprache der Fall, der vorgibt, von C zu kommen und etwas zu verwenden, das mit Zeigern verwandt ist, und es war bereits vor C der Fall).

Sie können dieses Problem mit zwei verschiedenen Verfahren lösen, abhängig von Ihrem Stil und dem in Ihrem Projekt verwendeten.

  • Zuerst kommt die defensing Weg -> man bedenkt, dass das Unterprogramm getötet werden sollte, bevor ein solcher Fehler auftritt (Null-Pointer-Fehler viel in der Software-Industrie kosten).

    public void silence(final Object key) { 
    
        if (key == null) { 
         throw new IllegalArgumentException("Key should not be null."); 
        } 
    
        Object oChain = getChain(key); 
    
        if (oChain == null || !(oChain instanceof Chain)) { 
         throw new IllegalArgumentException("Key should be mapped to an object from the Chain class type."); 
        } 
    
        Chain chain = (Chain)oChain; 
        if(checkPrecondition(chain)) { 
         chain.silence(); 
        } 
    } 
    
  • Der zweite Weg ist Offensive: der anrufende Code sollte damit umgehen und die subprocess hat nichts zum Absturz zu bringen!

    public boolean silence(final Object key) { 
        if (key == null) return false; 
        Object oChain = getChain(key); 
        if (oChain == null || !(oChain instanceof Chain)) return false; 
        Chain chain = (Chain)oChain; 
        if(!checkPrecondition(chain)) return false; 
        chain.silence(); 
        return true; 
    } 
    

Bitte beachten Sie, dass ich nehme an, die checkcondition Methode ein Boolean zurückkehrt und dass sein einziges Argument sollte ein Objekt von der Kettenklasse sein.

+0

Ich schätze es, dass Sie sich die Zeit nehmen zu antworten, vielen Dank. Allerdings sehe ich keine Antwort auf mein Problem.Das Problem ist, dass Eclipse sich mit dem Aufruf von checkPrecondition() beschwert, obwohl es kein Problem gibt (Null-Case wird behandelt). Mit dem Aufruf nicht vorhanden, ** ist ** ein Problem (Null-Fall ** nicht ** behandelt), aber Eclipse klagen nicht. Eine Erhöhung der Code-Größe im Wesentlichen nach oben ist in unserem Fall keine Option. Auf der anderen Seite ist Ihr Hinweis, nicht nur gegen null, sondern auch gegen "instanceof" zu prüfen, gut getroffen. – FreeSpirit64

+0

Was ich mit "tell Eclipse" meine, ist folgendes: PC lint erlaubt mir zum Beispiel zu sagen, dass ein bestimmter benutzerdefinierter Ausdruck wie eine Assertion wirkt und während der statischen Code-Analyse als Synonym zu "assert" gesehen werden soll. Das macht viel Sinn und das ist es, was ich in Eclipse suche. – FreeSpirit64

+0

Mit meiner Version: nein beschwert sich. Nun, ich verstehe, dass Sie verwirrt sind, aber Ihr Code scheint überhaupt nicht zu kompilieren (besonders der * checkPrecondition * Aufruf, weil Sie einen Boolean übergeben, wo ein anderer Typ erwartet wird, zumindest hoffe ich das). Normalerweise versuchen Sie einfach nicht, den Eclipse Linter zu modifizieren, was wahrscheinlich eine der größten Hilfen ist, die Sie jemals haben werden (die Jungs dahinter sind sehr gute Programmierer und Sie können ihnen vertrauen). Wenn Sie das tun, brauchen Sie Eclipse nicht mehr. Das Aktualisieren eines Codes ist wesentlich einfacher als das Ändern von Eclipse selbst: Stellen Sie sich vor, Sie ändern das Linter-Update oder die Neuankömmlinge im Projekt. –

Verwandte Themen