Allgemeines Exception Handling

Java-Forum Java-Grundlagen
1

Auch wenn es etwas designtechnisches ist, meiner Meinung nach, gibt es für folgendes eine Art “Konvention”?

public String toLower(String input){return input.toLowerCase()};

public void main(){
MyObject obj = new MyObject("World"); //Konstruktor weggelassen, der setzt z.B. nur eine Variable
String lowerName = toLower(obj.getName());

//mache dann irgendwas mit lowerName
}

Was ist nun wenn z.B. der Name nicht gesetzt werden muss und somit null zurückliefert. Wie baut man dann die Exception dazu? In die Methode, in der dann der Übergabewert falsch ist, oder vorher, vor dem Aufruf?
Also

public String toLower(String input){
if(input == null) Exception;
else
return input.toLowerCase()};

//oder
if(obj.getName() != null)
String lowerName = toLower(obj.getName());

So an sich würde ich Version1 präferieren. Wenn man aber mit der Variablen weiterarbeitet muss man ja doch wissen ob sie null ist, also kann man ja die zweite Version nutzen. Aber vllt. kann da nochmal wer anders was dazu sagen .)

2

Validierung von Parametern sieht man häufig am Anfang der Methode mit direktem throw.
Das spart auch eine ganze Menge if-else ein.

Falls die Validierung zu groß wird (z.B. 9 Zeilen gestaffelteif(...) throw ... auf 3 Zeilen Produktivcode), kann man die validierung auch in einer void-Methode machen (erster Aufruf in der vorigen Methode), die dann die Exceptions hochwirft.

Gruß

3

Hm, daran hab ich nun gar nicht gedacht, das so zu lösen bzw. zu betrachten .O, guter Punkt.

€: Wobei es dabei zwischen den checked/unchecked Nutzern Seitenweise Diskussionen gibt was nun besser ist

4

Unchecked/Nicht unchecked macht da erstmal keinen Unterschied.
An einer privaten Methode wird es nicht Teil der API und wie man die Schnittstelle der öffentlichen Methode gestaltet entscheidet man auch selbst.
Intern kann man z.B. auch ohne Probleme Checked-Exceptions fangen und in eine Unchecked-Exception verpacken.

Gruß

5

Kurz einmal konkret zum Prüfen auf null:
Seit Java7 gibt es die Klasse [java.util.Objects](http://docs.oracle.com/javase/7/docs/api/java/util/Objects.html#requireNonNull(T, java.lang.String)), die u.a. die Methode “requireNonNull(T obj, String message)” anbietet. Damit kann man sich das if und throw sparen.

6

wenn null ein zulässiger Wert ist sollte gar keine Exception geworfen werden. Die Methode sollte geeignet damit umgehen und beispilsweise einen leeren String zurück liefern, so dass es für den nachfolgenden Code transparent bleibt.

bye
TT

7

Also die Klasse Objects ist mir noch nicht aufgefallen… netter Tip.
Ansonsten lagere ich solche n Zeiler schonmal in check-Methoden aus:

  if(obj == null) {
    throw new NullPointerException();
  }
}

private void checkRange(int index) {
  if(index < 0 || index >= max) {
   throw new IllegalArgumentException("index out of range" + index);
  }
}```Durch die Objects-Klasse erschliessen sich mir da völlig neue Möglichkeiten an die ich noch gar nicht gedacht habe. Ich werde wohl mal über eine weitere Utility-Klasse nachdenken müssen.
8

@Spacerat : auch zu deiner Lösung gibt es verschiedene Meinungen: NullPointerException oder IllegalArgumentException bei null werfen? Die zweite erscheint mir viel logischer.

9

[QUOTE=darekkay]@Spacerat : auch zu deiner Lösung gibt es verschiedene Meinungen: NullPointerException oder IllegalArgumentException bei null werfen? Die zweite erscheint mir viel logischer.[/QUOTE]Ok, anstandslos einverstanden.