Hallo,
naja, nicht immer sollte man Exceptions, die in einer Funktion auftreten, genau so an den Aufrufer weiterleiten. Im Javadoc ist das beschrieben mit den Lowlevel-Exceptions und den Highlevel-Exceptions. Beispielsweise, wenn man eine Komponente entwickelt mit einer Methode, und die soll irgendwas machen. Angenommen die Funktion muss eine Datei lesen (dabei kann eine IOException auftreten) und dann muss sie noch eine Datenbankverbindung herstellen (dabei kann eine SQLException) auftreten. Falls irgendwas davon fehlschlägt, muss die Methode auch fehlschlagen, da sie ihre Aufgabe sonst nicht erfüllen kann. Es wäre nun aber nicht gerade die beste Lösung, die IOException oder die SQLException einfach an den Aufrufer weiterzuleiten, weil vielleicht soll der ja gar nicht mitbekommen, wie die Methode genau ihre Aufgabe erledigt. Sondern falls sie fehlschlägt, liefert sie eine bestimmte Exception, z.B. "MeineMethodenException". Damit macht man nicht public void myMethod() throws IOException, SQLException, XPathException, _
NamingException ..... sondern
public void myMethod() throws MeineMethodenException .
Also in der Methode fängt man die IOException, SQLException usw. auf und wirft eine neue MeineMethodenException.
Das hat eigentlich nichts mit Umständlichkeit zu tun, sondern mit Kapselung. Der Aufrufer muss jetzt keinen Try-Catch-Block haben in der er jede dieser Ausnahmen abfängt, sondern er fängt nur die "MeineMethodenException" ab, die geworfen wird, wenn die Methode fehlschlägt (man kann zwar auch nur Exception auffangen, aber vielleicht braucht man ja einen größeren Try-Catch-Block, in dem man auch noch andere Exceptions gezielt auffangen will. Es ist nicht immer das Beste, einfach nur "Exception" aufzufangen).
Und wenn der Aufrufer doch wissen soll, was der Grund des Fehlschlagens ist, kann man eben den Grund (Cause) angeben, indem man die originale Exception mitliefert.
Beitrag wurde zuletzt am 14.03.11 um 20:25:28 editiert. |