Unbekannten Fehler abfangen

[HonniCilest]

Hallo zusammen,

ich hoffe es hat ggf. jemand einen guten Tipp für mich.

Bei einem Programm ist beauftragt einen Unbekannten Fehler als solches an verschiedenen Stellen anzuzeigen. Ich bin bisher so an herangegangen, dass ich die verschiedenen Fehler (Excpetions) in mehreren catch-Blöcken abgefangen und entsprechend reagiert habe. Ein unbekannter Fehler war für mich dann der Fehler, welcher durch einen letzten catch-Block abgefangen wurde. Dieser letzte catch-Block bezog sich generell auf Exception. Das hat grundsätzlich super funktioniert. Leider wird catch (Exception e) im späteren Entwicklungsprozess nicht akzeptiert, d.h. ich muss mir eine andere Herangehensweise überlegen und ich habe keine Idee wie ich sonst einen Unbekannten Fehler erkennen kann. Ebenfalls nicht akzeptiert wird catch (RuntimeException e) und catch (Throwable t).

Danke schonmal !

Gruß
HC

 

[vfl_freak]

Moin,

was meinst Du denn mit "wird nicht akzeptziert" ??
Von wem ????

Wäre es nicht eine Möglichkeit, als letzten Part einfach nur ein "else" dranzuhängen ??

Gruß
Klaus

 

[HonniCilest]

was meinst Du denn mit "wird nicht akzeptziert" ??
Von wem ????

Vom Kunden natürlich ^^ im Code-Review...

Wie würde hier eine "else" aussehen? Ich habe das noch nie im Zusamenhang mit try-catch gehört.

 

[Cromon]

Hallo HonniCilest

Dass dein Kunde catch(Exception) nicht akzeptiert ist schön zu hören. Gibt es in einem System unbekannte Fehler ist das System nicht brauchbar. Eine Möglichkeit dies zu handhaben: Design by Contract. Jede Methode definiert einen Vertrag mit Bedingungen. Rufst du diese Methode auf akzeptierst du diesen Vertrag. Dieser Vertrag kann aus verschiedenen Bedingungen bestehen, bekannt sind sicher: Vorbedingungen, Nachbedingungen, Fehlerbedingungen. Vorbedingungen können auf die Parameter sein (x darf nicht null sein, y muss geladen sein, usw) oder auch auf das Objekt, das die Methode beinhält (muss in der Welt sein, muss von der Datenbank geladen worden sein, usw) bezogen sein. Nachbedingungen können auf alles bezogen sein, was irgendwie mit der Methode in Kontakt kam, z.B. Parameter x wurde gelöscht, das Objekt der Methode ist nicht mehr in der Welt, Eintrag y wurde aus der Datenbank gelöscht, Rückgabewert ist XY, usw. Fehlerbedingungen geben an, wann welche Fehler auftreten können (z.B. Exceptions) und warum sie das tun.

Wird dies konsequent umgesetzt gibt es so etwas wie "unbekannte Fehler" nicht.

Viele Grüsse
Cromon

 

[vfl_freak]

Moin,

Wie würde hier eine "else" aussehen? Ich habe das noch nie im Zusamenhang mit try-catch gehört

ääh - ja ... ich meinte eigentich "finally" (ist wohl zu warm heute ) !
Denke aber jetzt, dass es in Deinem Kontext dann doch nicht das Gegebene ist !

Gruß
Klaus

 

[HonniCilest]

Hallo HonniCilest

Dass dein Kunde catch(Exception) nicht akzeptiert ist schön zu hören. Gibt es in einem System unbekannte Fehler ist das System nicht brauchbar. Eine Möglichkeit dies zu handhaben: Design by Contract. Jede Methode definiert einen Vertrag mit Bedingungen. Rufst du diese Methode auf akzeptierst du diesen Vertrag. Dieser Vertrag kann aus verschiedenen Bedingungen bestehen, bekannt sind sicher: Vorbedingungen, Nachbedingungen, Fehlerbedingungen. Vorbedingungen können auf die Parameter sein (x darf nicht null sein, y muss geladen sein, usw) oder auch auf das Objekt, das die Methode beinhält (muss in der Welt sein, muss von der Datenbank geladen worden sein, usw) bezogen sein. Nachbedingungen können auf alles bezogen sein, was irgendwie mit der Methode in Kontakt kam, z.B. Parameter x wurde gelöscht, das Objekt der Methode ist nicht mehr in der Welt, Eintrag y wurde aus der Datenbank gelöscht, Rückgabewert ist XY, usw. Fehlerbedingungen geben an, wann welche Fehler auftreten können (z.B. Exceptions) und warum sie das tun.

Wird dies konsequent umgesetzt gibt es so etwas wie "unbekannte Fehler" nicht.

Viele Grüsse
Cromon

Das sehe ich ja grundsätzlich genauso wie du!!! Die erwähnten Bedingungen wurden alle definiert und entsprechend von mir gehandelt. Ich bin auch der Meinung der unbekannte Fehler dürfte nicht auftreten, zumindest in der Theorie. Dennoch ist / war die Angabe eines unbekannten Fehlers Bestandteil der Beauftragung bzw. des Konzeptes - genau hier liegt das Problem! Ohne die Anforderung wäre ich nie auf die Idee gekommen soetwas zun tun, da mir dieser Stil auch nicht gefällt. Aber ich denke mittlerweile, dass dies ein Punkt ist, den man entsprechend argumentieren kann.