MSausKO schrieb am 6. September 2004 13:34
> Entwurfsmuster schrieb am 6. September 2004 12:24
> > Ich glaube nicht unbesehen alles, nur weil es von Bruce Eckel kommt.
> > Seine Argumentation gegen Checked Exceptions z.B. war katastrophal.
>
> Hallo! Ich beschäftige mich auch sein einiger Zeit mit der Frage der
> Checked Exceptions, bin für mich noch zu keinem Ergebnis gekommen.
> Gefällt Dir nur die Argumentation von Bruce Eckel nicht oder gefällt
> Dir auch das Ergebnis nicht? In beiden Fällen: warum?
>
Beides gefällt mir nicht.
Bruce argumentiert, daß es sich in der Praxis nicht bewährt hat und
man in der Praxis oft Beispiele findet, wo statt einer
Fehlerbehandlung eine leere catch - clause steht, die die Exception
"verschluckt" (ein Stil, den er in seinem Buch "Thinking in Java"
selbst etabliert hat).
Sein Argument ist also: Weil schlechte Programmierer (including
himself) checked Exceptions falsch benützen, sind checked Exceptions
schlecht.
Die Möglichkeit, die Exception durch Angabe im throws-clause der
Methode weiterzugeben, statt sie lokal zu behandeln, scheint ihm
nicht bekannt zu sein!?!
Er argumentiert, daß es angenehmer ist, wenn die Exception nicht
checked ist, und man selbst entscheiden kann, ob und wo man sie
fängt.
Er übersieht dabei, daß bei unchecked Exceptions jede Dokumentation,
welche Methode welche Exceptions wirft, bereits verlorengegangen ist
(inbesondere wenn man mit fremden Bibliotheken arbeitet und den Code
nicht zur Verfügung hat).
Die behauptete Lösung ist somit keine, man kann sie nicht vernünftig
implementieren, weil man nicht weiß, welche Exceptions auftreten
können.
Seine "Lösung": Checked Exceptions in unchecked Exceptions verpacken.
Das hat genau den beschriebenen Nachteil: Die Information, welche
Exception geworfen werden kann, geht verloren.
Meine Meinung:
Das richtige Exception-Handling setzt die Verwendung von
Exception-Kategorien / -Hierachien voraus.
Eine Kategorie wäre z.B. "ResourceNotAvailable" oder
"MissingPermission".
Die Exceptions der Implementierungs-Layer müßten dann Subklassen der
jeweiligen Kategorie sein, z.B. FileNotFoundException oder (gibt es
leider nicht) SQLPermissionException.
Definiert man Interfaces, gibt man die entsprechenden Kategorien in
der throws clause an. (Die alternative Lösung: Eine Exception pro
Software Layer, wobei diese die auslösende Exception als
Instanzvariable enthält. Wird seit JDK1.4 sogar offiziell
unterstützt.).
Leider hat man es bei der Definition der Exceptions in den Java APIs
oft an der notwendigen Sorgfalt missen lassen.
Das führt dann z.B. dazu, das man bei einer SQL-Query einen Timeout
setzen kann. Wird dieser überschritten, wird aber keine
SQLQueryTimeoutException geworfen, sondern nur eine allgemeine
SQLException (die auch durch einen Fehler in der Query ausgelöst
werden kann).
Gruß
Entwurfsmuster
> Entwurfsmuster schrieb am 6. September 2004 12:24
> > Ich glaube nicht unbesehen alles, nur weil es von Bruce Eckel kommt.
> > Seine Argumentation gegen Checked Exceptions z.B. war katastrophal.
>
> Hallo! Ich beschäftige mich auch sein einiger Zeit mit der Frage der
> Checked Exceptions, bin für mich noch zu keinem Ergebnis gekommen.
> Gefällt Dir nur die Argumentation von Bruce Eckel nicht oder gefällt
> Dir auch das Ergebnis nicht? In beiden Fällen: warum?
>
Beides gefällt mir nicht.
Bruce argumentiert, daß es sich in der Praxis nicht bewährt hat und
man in der Praxis oft Beispiele findet, wo statt einer
Fehlerbehandlung eine leere catch - clause steht, die die Exception
"verschluckt" (ein Stil, den er in seinem Buch "Thinking in Java"
selbst etabliert hat).
Sein Argument ist also: Weil schlechte Programmierer (including
himself) checked Exceptions falsch benützen, sind checked Exceptions
schlecht.
Die Möglichkeit, die Exception durch Angabe im throws-clause der
Methode weiterzugeben, statt sie lokal zu behandeln, scheint ihm
nicht bekannt zu sein!?!
Er argumentiert, daß es angenehmer ist, wenn die Exception nicht
checked ist, und man selbst entscheiden kann, ob und wo man sie
fängt.
Er übersieht dabei, daß bei unchecked Exceptions jede Dokumentation,
welche Methode welche Exceptions wirft, bereits verlorengegangen ist
(inbesondere wenn man mit fremden Bibliotheken arbeitet und den Code
nicht zur Verfügung hat).
Die behauptete Lösung ist somit keine, man kann sie nicht vernünftig
implementieren, weil man nicht weiß, welche Exceptions auftreten
können.
Seine "Lösung": Checked Exceptions in unchecked Exceptions verpacken.
Das hat genau den beschriebenen Nachteil: Die Information, welche
Exception geworfen werden kann, geht verloren.
Meine Meinung:
Das richtige Exception-Handling setzt die Verwendung von
Exception-Kategorien / -Hierachien voraus.
Eine Kategorie wäre z.B. "ResourceNotAvailable" oder
"MissingPermission".
Die Exceptions der Implementierungs-Layer müßten dann Subklassen der
jeweiligen Kategorie sein, z.B. FileNotFoundException oder (gibt es
leider nicht) SQLPermissionException.
Definiert man Interfaces, gibt man die entsprechenden Kategorien in
der throws clause an. (Die alternative Lösung: Eine Exception pro
Software Layer, wobei diese die auslösende Exception als
Instanzvariable enthält. Wird seit JDK1.4 sogar offiziell
unterstützt.).
Leider hat man es bei der Definition der Exceptions in den Java APIs
oft an der notwendigen Sorgfalt missen lassen.
Das führt dann z.B. dazu, das man bei einer SQL-Query einen Timeout
setzen kann. Wird dieser überschritten, wird aber keine
SQLQueryTimeoutException geworfen, sondern nur eine allgemeine
SQLException (die auch durch einen Fehler in der Query ausgelöst
werden kann).
Gruß
Entwurfsmuster