Moin. Haette da eine Frage an euch.
Ich meine mich dunkel daran erinnern zu koennen, dass in SE mal gesagt wurde, dass try/catch Bloecke ausschliesslich der Fehlerbehandlung dienen und nicht als Kontrollsturktur missbraucht werden duerfen. Erinnere ich mich da richtig?
Falls ja, warum ist das so? Wie gehe ich vor, wenn ich im Fehlerfall einen Alternativplan einschlagen moechte und nicht die Moeglichkeit habe schlicht irgendwas auf null zu testen?
if(foo == null) {
stmt0;
} else {
stmt1;
}
ist besser als:
try {
foo.noop;
stmt0;
} catch(Exception e)
{
stmt1;
}
ist es das, was du meintest?
Hinweis: null ist nicht zwangsläufig ein Fehler.
So in etwa, ja. Das Problem ist, dass ich eine sehr abgeschlossene Schnittstelle habe, bei der ich im Fehlerfall keinen Rueckgabewert (z.B. null) bekomme sondern lediglich eine Exception.
Die Frage ist, ob ich auf das sichere Ausfuehren des catch Blocks vertrauen und dort etwa einen boolean von true auf false setzen kann um weitere Massnahmen einleiten zu koennen.
Wenn alles was du kriegen kannst eine Exception ist, musst du wohl try/catch nutzen.
bool fail = false;
try {
foo.bar();
} catch(Exception e) {
fail = true;
}
if(fail) {
}
finde ich persönlich ok.
Oder du baust eine eigene Exception und benutzt "throw" im Fehlerfall?
Danke erstmal Wulf, ich werde noch einbisschen googlen und schauen, wer sich hier noch alles zu Wort meldet.
Oder du baust eine eigene Exception und benutzt "throw" im Fehlerfall?
???
Ein Grund, weshalb man try/catch-Blöcke nicht als Kontrollstruktur missbrauchen soll, ist, dass sie dafür schlicht und ergreifend nicht da sind. Es erhöht einfach ungemein die Verständlichkeit des Quelltextes, wenn Sprachkonstrukte für das benutzt werden, wofür sie da sind. Wenn ein anderer Entwickler irgendwann den Code sieht, soll er erkennen können, was da passiert. Und eine try/catch-Block sagt ihm, hier findet eine Ausnahmebehandlung statt. Für reguläre Verzweigungen sind if/then/else-Blöcke da.
Nun kann man im konkreten Fall natürlich darüber streiten, was ein regulärer Programmpfad und was ein Ausnahmefall ist. Ist z.B. eine fehlerhafte Benutzereingabe eine Ausnahme oder nicht? In vielen Fällen hängt das sicher auch vom jeweiligen Kontext ab, z.B. sind bei freien Textfeldern ungültige Eingaben genauso wahrscheinlich wie richtige. Bei DropDown-Feldern ist eine fehlerhafte Eingabe eher eine Ausnahme.
Wenn man eine Methode aufruft, die im Fehlerfall eine Exception wirft, kann, soll und muss man natürlich eine entsprechende Fehlerbehandlung im catch-Block vorsehen (es sei denn, man will sie einfach weiterwerfen). Kommt es zu dieser Exception, wird dieser natürlich auch ausgeführt.
Eine Konstruktion wie in Wulfs Beispiel finde ich persönlich nicht so schön. Ich würde ein schlichtes try {
foo.bar();
} catch(Exception e) {
//do something
} bevorzugen.
Ist der Fehler vorhersehbar, weil er z.B. nur auftritt, wenn eine bestimmte Vorbedingung nicht erfüllt ist, sollte man die Vorbedingung natürlich testen, bevor man die Methode überhaupt aufruft. Aber bei solchen Fehlern sollte eigentlich auch eher eine RuntimeException geworfen werden, die keinen try/catch-Block erzwingt, da ihnen schließlich Programmierfehler zugrunde liegen, wenn sie trotz Vermeidbarkeit auftreten.
Diese Grundlegenden Dinge sind mir schon klar. Die Frage ist vielleicht etwas missverständlich formuliert: Ist die try/catch methode genauso zuverlässig wie eine if/else Anweisung? Da es keinerlei Andeutungen in diese Richtung gab gehe ich jetzt mal davon aus. Google brachte auch nichts ähnliches.
Danke erstmal Wulf, ich werde noch einbisschen googlen und schauen, wer sich hier noch alles zu Wort meldet.
Oder du baust eine eigene Exception und benutzt "throw" im Fehlerfall?
???
Er meint wohl so was wie:
http://www.programmersbase.net/Content/Java/Content/Tutorial/Java/Exception.htm
Ist die try/catch methode genauso zuverlässig wie eine if/else Anweisung?
Ich weiß nicht genau, worauf Du hinaus willst. Natürlich funktioniert das Konstrukt so, wie es soll. Wäre ja schlimm, wenn nicht. Also, wenn eine Exception geworfen wird, wird der catch-Block ausgeführt. Wann und wie eine Exception geworfen wird, hängt natürlich vom verwendeten Dienstleister ab. Aber eigentlich sollte man davon ausgehen können, dass der sich so verhält, wie in seiner Schnittstelle beschrieben. Schlampigkeit und Bugs kann es natürlich immer geben, aber darauf sollte man seinen eigenen Code nicht ausrichten.
Allerdings soll der Fall, dass eine Exception geworfen wird, nur eintreten, wenn etwas schief läuft. Und wieso soll man sich irgendwo darauf verlassen wollen, dass etwas schief läuft? Das ergibt doch keinen Sinn. Man geht doch eigentlich davon aus, dass alles richtig funktioniert, und für den Fall, dass doch nicht, definiert man seine Ausnahmebehandlung im catch-Block.
Oder du baust eine eigene Exception und benutzt "throw" im Fehlerfall?
???
public void foo() throws MyException
{
try
{
//do something
}
catch (SomeException e)
{
throw new MyException();
}
}
Danke erstmal Wulf, ich werde noch einbisschen googlen und schauen, wer sich hier noch alles zu Wort meldet.
Oder du baust eine eigene Exception und benutzt "throw" im Fehlerfall?
???
Er meint wohl so was wie:
http://www.programmersbase.net/Content/Java/Content/Tutorial/Java/Exception.htm
Was ich meinte war: Ich sehe nicht, wie mich das vom try/catch-Block Problem wegführen soll.
Allerdings soll der Fall, dass eine Exception geworfen wird, nur eintreten, wenn etwas schief läuft. Und wieso soll man sich irgendwo darauf verlassen wollen, dass etwas schief läuft? Das ergibt doch keinen Sinn
Tut es in diesem Fall ob der doofen API. Analysiere ein Bild nach einem bestimmten Muster. Wurde dieses Muster gefunden, liefere mir die Koordinaten. Schlägt die Suche fehl, wird eine Exception geworfen.
Aber naja, die Frage wurde beantwortet. Ich danke euch!
Analysiere ein Bild nach einem bestimmten Muster. Wurde dieses Muster gefunden, liefere mir die Koordinaten. Schlägt die Suche fehl, wird eine Exception geworfen.
Wurde das Muster gefunden, gib' eine Liste der Koordinaten zurück, an denen es gefunden wurde. Wurde es nicht gefunden, gib' eine leere Liste zurück. Wurde das Bild nicht gefunden, *dann* wirf' eine exception.
Ja fein. Nur habe ich keinen Einfluss auf diesen Prozess. Es wird eine Exception geworfen und eben keine leere Liste zurückgegeben. Noch genauer, ich bekomme nichtmal die Koordinaten sondern es wird direkt eine vorher festgelegte Aktion (z.B Mausklick) ausgeführt.
Ich habe die Mustererkennung nunmal nicht geschrieben. Natürlich könnte ich mich da einarbeiten und daran rumbasteln, aber diese Arbeit wollte ich vermeiden. Wenn try/catch zuverlässig ausgeführt wird, brauche ich es ja auch nicht.
Klassisches Beispiel für Missbrauch des Exception-Mechanismus.
Aber klar, wenn die API so ist, musst Du entsprechend damit umgehen und dann kommst Du um try/catch nicht herum. Damit Dein eigentlicher Code schöner bleibt, gäbe es noch die Möglichkeit das try/catch-Prozedere in einer Wrapper-Klasse zu kapseln, die Dir die Dienstleistung der Bilderkennung mit einer vernünftigen Schnittstelle anbietet.
