Es ist sehr verlockend, eine einzige zentrale Stelle für die Fehlerbehandlung einzubauen, statt an jeder Stelle, an der Fehler auftreten können, eine eigene Reaktion zu implementieren. Das hat aber zur Folge, dass du nur noch allgemein auf Fehler reagieren kannst und dem Anwender nicht mehr die beste Alternative aus seiner Sicht in einer bestimmten Situation bieten kannst.
Bei DB-Fehlern, Warnings, Notices etc. gebe ich eine 'System kaputt' Meldung aus. Was Anderes halte ich für unverantwortlich. Wenn was vom Konzept abweicht muss das System gestoppt werden.
Wenn beispielsweise ein Bestellvorgang aus technischen Gründen nicht durchgeführt werden kann, sollte man den Anwender dabei unterstützen, seine Bestellung auf alternativem Weg auszuführen (vielleicht per Mail), sonst bestellt er bei der Konkurrenz. Also kann man den Fehler nicht nur generell abfangen und dem Anwender ein "System kaputt" präsentieren, sondern muss individuell in den else-Zweig was Sinnvolles, möglichst Zielerreichendes notieren. Dass zusätzlich der Administrator eine Benachrichtigung braucht, steht außer Frage. Auch dabei muss man manchmal differenzieren. Ist es nur etwas Unbedeutendes, muss man den Admin nicht aus dem Bett klingeln. Ist es hingegen ein kritischer Fehler in einem wichtigen produktiven System, wäre eine SMS oder ähnliches angebracht.
Nettes Beispiel! :-)
Eine Fehlermeldung sollte er nur zu sehen bekommen, wenn er dran schuld ist (zum Beispiel bei unerlaubten Eingabe). Ansonsten sollte er die System-kaputt-Meldung nur bekommen, wenn gar nichts anderes mehr geht.
Das ist implementiert, wird auch von den richtigen "Systemfehlern" unterschieden!