Halli und Hallo,
eine sehr interessante Diskusion, so ich finde. Also aus meiner Sicht ist es nicht falsch Anwendungsexceptions zu entwicken. Natürlich kommt es auf den tieferen Sinn an.
Sinn einer Excepion, wie hier schon gesagt wurde, soll immer eine Ausnahmebehandlung sein, also nichts fachlich Reguläres.
So weit ich es programmierhistorisch verfolgen konnte entstand der Wunsch nach Excepions vermutlich auf diese Weise....
In der Prozeduralen Welt gab es vor allem in der Sprache C (und ähnlchen), Rückgabewerte, die dann mittels Fallunterscheidung (if-then-else oder switch) abgefragt wurden, um zu erfahren, ob etwas geklappt hat oder nicht und warum nicht etc.
Nun ist es aber so, dass, wenn man jeden Funktionsaufruf, der Erfolgsmeldungen (hier seien mathematische funktionen außen vor) rausgibt, anschließend mit Fallunterscheidungen beglückt, der Code, aus lauter Fallunterscheidungen bestehend, irgenwann unübersichtlich werden kann, da das eigetnlich Fachliche nur wenige Zeilen des Gesamtcodes betreffen würde. Erschwehrend kommt hinzu, dass z.B. C wenig restrictiv ist, so dass viele undisziplinierte Programmierer die Erfolgsabfragen nicht immer machen. Also dort ist mit reinen Returncodes gelegentlich Gefahr im Verzuge, da vielleicht der Programmierer nicht alles abgetestet hat, sei es aus Faulheit oder aus Vergesslichkeit.
Exceptions sollten eigetnlich diese 2 Phenomäne lösen, 1. durch gnadenlosen Abbruch des funktionsblockes mit dem Ziel nicht jede Mehtode mit Fallunterscheidungen beglücken zu müssen und den Code damit wweniger aufzublähen, 2. mit selbigem Mechnaismus der Vergesslichkeit einiger Programmierer entgegenzuwirken.
Es ist, so sehe ich es zumindest, natürlich eine Gradwanderung was man als Entwickler für ein Ausnahmeverhalten hält und was nicht.
Der Exceptionmechnanismus ist, wie hier schon von den vorherigen Beträgen angemerkt wurde, mit Overhead verbunden. Jedoch sollte man sich überlegen, ob dieser Overhead bemerkbar ist oder nicht. In einer Dialoganwendung ist des dem Anwender egal, ob etwas sagen wir mal 1 millisekunde oder 100 millisekunden dauert. Er bekommt es gar nicht mit. In einer langlaufenden Batchanwendung kann das schon wieder anders sein, denn hier summiert es sich.
Eingabefehler durch Anwender, sind meines Erachtens nicht notwendigerweise falsch als Ausnahme zu empfinden. Ich selbst verwende da einen Exceptionhandler-mechanismus (er ist quasi nach Dekorater-Pattern eigengebraut)
Damit ist es möglich z.B. bei Anwendereingabefehlern, die nicht direkt durch das verwendete Guielement unterbunden werden können, wie z.B. Texteingabefeld lässt nur Zahlen zu, sehr codezentralisiert Fehlermeldungen auszuspucken. Das kommt dann z.b. zum Tragen wenn man im Code nur mit Fehlerzahlen rumjongliert und dann irgenwann zentralisiert in Texte umwandeln möchte. Ein Dialog, der den Benutzer dann auf seinen Fehler hinweist, würde nicht überall in jedem Panel bekannt sein, sondern nur dem speziellen Exceptionhandler, der selbst halt nur durch eine dekorierte ExceptionHandlerKlasse mitells Interface aufgerufen wird.
man würde also im Code in den meisten Fällen nur noch folgendes sagen
Code:
main()
{
...
ExceptionHandler.setHandler(new MyExceptionHandler())
...
}
somefunction(Object x, Object y, Object z)
try
{
... fachlicher Code ohne Abfrage auf aufgetretene Fehler...
}
catch (Exception ex)
{
ExceptionHandler.handleException(ex)
}
Anstelle von
Code:
try
{
... fachlicher Code ohne Abfrage auf aufgetretene Fehler...
}
catch (DieseException e1)
{
--- reagiere auf e1
}
catch (JeneException e2)
{
--- reagiere auf e2
}
catch (DieseException ex)
{
--- reagiere auf ex
}
in Code ganz ohne Exceptions wäre es vermutlich so ...
Code:
...
{
...
int rc = funkotionA (x, y, z)
switch(rc)
{
case HAT_GEKLAPPT:
rc = funkotionB ()
switch(rc)
{
....
}
....
case EINBISSLE_FALSCH:
....
case GANZ_FALSCH:
....
default: // unbekannter returncode
....
}
rc = funkotionC ()
switch(rc)
{
....
}
...
}
Und da es nur wenige sehr disziplinierte Entwickler gibt (zumindest traf ich selbst nur auf sehr wenige), die braf alles erdenkliche abfangen zumal der Code ohne Exceptions wie im letzten angedeuteten Beispiel aufgebläht wird, können mit unter anwedungsfachliche Exceptions sinnvoll sein.
aber wie dem auch sei ... ein interessantes Diskusionsthema
Takidoso