Exception Handling – Exceptions nicht zur Ablaufsteuerung missbrauchen – Teil 2
In einem Vorgängerartikel haben wir bereits gesehen, warum es keine gute Idee ist, Exceptions zur Ablaufsteuerung zu missbrauchen. Hier folgt ein Beispiel, wie man es leider oft in der Praxis findet.
In der Java-Persistence-API verführt die Methode getSingleResult[1] dazu, Exceptions zur Ablaufsteuerung zu missbrauchen. Denn sie wirft eine NoResultException[2], wenn kein Ergebnis gefunden wurde. Was ist aber in dem Fall, wenn wir 0 oder 1 Ergebnis erwarten und beides valide Fälle sind? Leider sieht man dann oft Code, der wie folgendes Beispiel aussieht:
getSingleResult[1] sollten wir nur verwenden, wenn wir exakt ein Ergebnis erwarten und alles andere ein Fehlerfall ist! Da dies hier nicht der Fall ist, verwenden wir lieber die Methode getResultList.
Wer aufmerksam gelesen hat, mag bemerkt haben, dass dies semantisch nicht ganz identisch ist. Denn für den Fall mehrerer Ergebnisse wird jetzt keine NonUniqueResultException mehr geworfen. Dies lässt sich aber leicht ergänzen.
Ja, das ist etwas geschwätziger als die ursprüngliche Variante. Aber dafür wird die Intention klarer ausgedrückt.
Fazit
Bedauerlicherweise bietet die Java-Persistence-API keine Methode getZeroOrOneResult, die ein optionales Ergebnis liefern würde. So wird man verführt, die getSingleResult[1] für die falschen Zwecke zu verwenden und die NoResultException[2] zur Ablaufsteuerung zu missbrauchen. Auch wenn dies etwas mehr Code erfordert, sollte man lieber die saubere Variante implementieren. Denn so wird unmissverständlich zwischen Fehlerfall und Ablaufsteuerung unterschieden.
[1] Javadoc zu Query#getSingleResult()
[2] Javadoc zu NoResultException
Bildnachweis:
– Das Titelbild zur Blogserie „Exception Handling“ basiert auf einer Grafik von mohamed_hassan auf Pixabay.
