SpotBugs Type DCN_NULLPOINTER_EXCEPTION und Type EI_EXPOSE_REP

[Hein_nieH]

Hallo,

Nachdem ich jetzt endlich SpotBugs nutzen kann versuche ich meinen code entsprechend der Warnungen zu verbessern
was mir mehr schlecht als recht gelingt.
Ich habe daher zunächst zwei Fragen zu Warnungen in SpotBugs.

1. DCN_NULLPOINTER_EXCEPTION
ich verwende in meinem code öfter das try/catch Blöcke.
Fange ich in einem Catch Block eine NullPointerException ab so erhalte ich bei SpotBugs die Warnung Type DCN_NULLPOINTER_EXCEPTION.
Leider liefert SpotBugs für diese Warnung keine Erklärung.
Weiss jemand, was die Entwickler von SpotBugs bei dieser Warnung beabsichtigt haben?

2. EI_EXPOSE_REP
Weiterhin ist für mich unklar wie ich der Warnung Type EI_EXPOSE_REP begegnen kann.
Diese Warnung erscheint immer dann, wenn ich in einer Funktion ein Objekt zurückgebe.
Kann mir hier jemand mal die Lösung an einem Codeschnipsel erklären?

Kennt jemand eine Quelle, in der die Warnungen auf deutsch erklärt werden?

Gruss Hein_nieH

 

[LimDul]

Man sollte möglichst vermeiden, Exceptions zur Programmsteuerung einzusetzen. Insbesondere eine Nullpointer-Exception ist in weit über 99% der Fälle ein Programmierfehler. Anstelle die zu fangen, sollte man den Code fixen, der zur Exceptions führt.

 

[Hein_nieH]

Hallo renitent,

vielen Dank für die Mühe

Zum Thema DCN_NULLPOINTER_EXCEPTION:
Ich würde das für mich so interpretieren:
Das Abfangen einer NullPointerException in einem catch block wäre ein schlechter Programmierstil.
Besser ist es durch andere Prüfungen wie z.B. if (objekt == null) einen Test zu machen.
Liege ich da richtig.

Bei DCN_NULLPOINTER_EXCEPTION habe ich mir so etwas schon gedacht.

Naja nun will ich mich noch durch die anderen Warnings durcharbeiten, um deren Sinn zu verstehen ...

Gruss Hein_nieH

 

[Oneixee5]

Bug descriptions — spotbugs 4.8.4 documentation

DCN: NullPointerException caught (DCN_NULLPOINTER_EXCEPTION)

According to SEI Cert rule ERR08-J NullPointerException should not be caught. 
Handling NullPointerException is considered an inferior alternative to null-checking.

This non-compliant code catches a NullPointerException to see if an incoming parameter is null:


boolean hasSpace(String m) {
  try {
    String ms[] = m.split(" ");
    return names.length != 1;
  } catch (NullPointerException e) {
    return false;
  }
}

A compliant solution would use a null-check as in the following example:


boolean hasSpace(String m) {
    if (m == null) return false;
    String ms[] = m.split(" ");
    return names.length != 1;
}

Auf deutsch:

Nach der SEI Cert Regel ERR08-J sollte NullPointerException nicht abgefangen werden.
Die Behandlung von NullPointerException wird als minderwertige Alternative zur
Null-Prüfung angesehen.

 

[Oneixee5]

Bug descriptions — spotbugs 4.8.4 documentation

EI: May expose internal representation by returning reference to mutable object (EI_EXPOSE_REP)

Returning a reference to a mutable object value stored in one of the object's fields exposes
the internal representation of the object.  If instances are accessed by untrusted code, and
unchecked changes to the mutable object would compromise security or other important properties,
you will need to do something different. Returning a new copy of the object is better approach
in many situations.

EI: Darf interne Darstellung durch Rückgabe eines Verweises auf ein veränderbares Objekt
preisgeben (EI_EXPOSE_REP)

Die Rückgabe eines Verweises auf einen veränderbaren Objektwert, der in einem der Felder
des Objekts gespeichert ist, legt die interne Darstellung des Objekts offen.  Wenn nicht
vertrauenswürdiger Code auf Instanzen zugreift und ungeprüfte Änderungen an dem
veränderlichen Objekt die Sicherheit oder andere wichtige Eigenschaften gefährden würden,
müssen Sie etwas anderes tun. Die Rückgabe einer neuen Kopie des Objekts ist in vielen
Situationen der bessere Ansatz.

 

[KonradN]

Generell sollte man bei allen Regeln der Statischen Codeanalyse den Sinn verstehen und genau überlegen, welche Regeln Sinn machen und welche Regeln keinen Sinn machen.

Die EI und EI2 Regeln von Spotbugs sind sehr wichtig. Aber das sind Regeln, die ich nicht starr umsetze und in meinen Projekten habe ich dies Regeln auch durchaus ausgeklammert. (Wenn man sich die GitHub Projekte anschaut von mir, die ich regelmäßig verlinke (JavaMavenApp und das JavaFX Pendant), dann sind die z.B. in dem Exclude File von Spotbugs. Ich meine auch bei JAdventure.

Das Problem ist halt, dass man die Kapselung damit bricht. Aber das muss nicht zwangsläufig ein Problem sein. Man muss es aber halt durchaus kritisch betrachten.

So ist es z.B. üblich bei Oberflächen: Man muss sich also nur Swing oder JavaFX ansehen.

Es ist also wichtig, seht gut auf die Kapselung zu achten und zu überlegen, wo diese Sinn macht oder eben nicht. Wenn ich in JavaFX eine Property nach außen gebe, dann ist das ein Bestandteil des Interfaces.

Hinkendes Auto Beispiel:
Will ich bei einem Auto von außen im Motor die Ventile steuern? Da wird man jetzt schnell denken: Bloß nicht, das ist nur Sache des Motors!
Aber es ist denkbar, dass zu dem Motor ein externes Motor-Steuergerät existiert. Daher gibt es ein viel größeres Interface. Und separate Dinge. Wer weiss, was da die Anforderungen sein könnten, die so ein Design hervor bringen könnten. Man muss nur anfangen, da etwas herum zu spinnen. (Wenn das Interface spezifiziert ist, dann können diverse Hersteller Motoren oder Steuergeräte herstellen und die lassen sich beliebig mixen!)

Das nur als kleiner Hinweis. Statische Codeanalyse ist nur ein Tool oder eine Toolsammlung. Ob ein Tool passt oder nicht, muss man individuell betrachten.

 

[Hein_nieH]

Hallo,

danke für die Hinweise.
So einigermaßen fang ich an die Sache zu verstehen

Gruss Hein_nieH