Ich werfe immer dann Exceptions, wenn ein Fall auftritt der ein Verhalten erfordert, das nicht von der Methode selbst kontrolliert werden soll. Andernfalls handhabt die Methode den Fehler entsprechend. Hilfreich ist in solchen Fällen auch, filterbare Log-Ausgaben zu generieren.
Durch Fehlercodes über Rückgabewerte zu kommunizieren finde ich befremdlich. Man kann nur wenig Informationen über den Fehler mitgeben, und es passiert allzuleicht, Fehler zu ignorieren (Viel Spaß beim Debuggen). Deswegen sollte diese Variante weitmöglichst vermieden werden.
Noch was zum Thema warum Exceptions nur selten genutzt werden sollten.
1.) Sind Exceptions im Code äquivalent zu nicht-lokalen und optionalen GOTO's. Sie brechen den Programmfluss an einer Stelle hart ab, und der nächste Einsprungspunkt liegt (oder auch nicht) in komplett anderem (nämlich ggf. irgend einem X Ebenen höher aufrufenden) Codeblock. Das macht die ganze Sache zu Spaghetti- und unwartbaren Code.
Es hängt stark von "selten nutzen" ab - aber im Endeffekt sind Exceptions keineswegs GoTos, und haben einen sehr linearen Verlauf. Wenn ein Fehler auftritt, den man in der Methode selbst nicht behandeln kann hat man mehrere Möglichkeiten:
1. man ignoriert den Fehler (ouch)
2. man meldet dem Aufrufer über Rückgabewert oder Parameter, dass ein Fehler aufgetreten ist
3. man schmeißt eine
Exception
Excepions sind da die Wahl der Qual. Zudem bieten sie weitaus saubereren Code und können viel Informationen über den Fehler mitgeben, um die bestmögliche Fehlerbehandlung zu erlauben.
2.) Gehen die Designer des Compilers und der Runtime auch davon aus, das Exceptions seltene Ausnahmefälle darstellen. Dementsprechend ist der Code für das
Exception-Handling üblicherweise (da nur selten verwendet) nicht hochoptimiert. Das Werfen einer
Exception ist in Sachen Performance in aller Regel eine sehr teure Operation.
Richtig. Normalerweise wird auch in Performance-intensiven Anwendungen erst die Eingaben auf Fehler geprüft, dann der aufwendige Task gestartet.