Tach!
Nehmen wir mal an dieses ganze SQL Zeugs würde in einer Funktion stehen, dan wäre das ganze sogar noch übersichtlicher:
try {
my_mysql_connection(); //--- wird eventuell Exception
} catch {
// Reaktion auf Fehler
// - Alternative für den Anwender
// - Meldungstext für den Admin loggen
}
> dann brauche ich an jeder Stelle ein try catch, sobald ich my\_mysql\_connection() aufrufe.
Ja, wenn du das quer im Quelltext verteilst, brauchst du an jeder Stelle eine Prüfung. Das ist aber prinzipiell unabhängig von der Entscheidung, ob auf Fehler mit Exceptions oder herkömmlich reagiert werden soll. Die wesentlichere Frage ist, an welcher Stelle auf Fehler sinnvollerweise bezogen auf den Anwendungsfall reagiert werden kann, und da muss dann die Behandlung erfolgen.
> Wenn die aufrufe in der Nähe voneinander stehen kann man das ganze freilich in einen try catch packen.
Ist es denn sinnvoll, eine Fehlerbehandlungsstelle über mehrere Arbeitseinheiten zu spannen? Kommt drauf an. Wenn die Arbeitseinheit "eine Abfrage" lautet, dann würde ein try-catch sinnvoll sein. Weiter "oben" heißt die Arbeitseinheit "hole mir die Daten eines Users" und umfasst vielleicht mehrere Abfragen. Wenn das in einem try-catch steht, spannt sich das auch nur über eine Arbeitseinheit. Die Abfrage kann üblicherweise nicht entscheiden, was "weiter oben" für eine Alternative sinnvoll wäre, also reicht sie nur die Exception hoch. Der "oberen" Arbeitseinheit ist in dem Fall mal egal, welche Datenabfrage fehlerhaft war, mit der Lücke ist der User nicht darstellbar. Aber es gibt eine Alternative, weswegen die Exception hier gefangen und erledigt werden kann.
> Wenn die Aufrufe aber in andere Funktionen wiederum gepackt sind, brauche ich in diesen Funktionen auch wieder einen try catch Zweig und wenn man da nur die Exception weiter gibt.
Ja, wie bei herkömmlicher Fehlerbehandlung auch.
> Kombiniert mit einem jeweiligen Plan B ist das enorm viel Code. Aber die Lösung hab ich ja jetzt für dieses Problem des vielen Codes. Man darf halt nur nicht vergessen für Fälle wo ein Plan B sinnvoll erscheint diesen auch zu implementieren.
Je komplexer die Aufgabenstellung wird, desto mehr Fehlerbehandlung muss rein. Das kann man nicht vermeiden, wenn das Programm robust sein soll.
> Wobei mich das zur nächsten Frage bringt. Wie erzwingt man eine Exception bei einem Unittest?
Man baut den Testfall so, dass die zu testende Einheit was zu meckern hat. Manch ein Testframework fängt Exceptions ab, ansonsten kann man den Delinquenten auch selbst in einen try-catch packen und den Test für gut befinden oder dessen Fehlschlagen (wenn keine Exception ausgelöst wurde) weitermelden.
dedlfix.