Sollte die Methode im data access object (DAO) zu werfen oder fangen Sie die Ausnahme?

Ich habe eine Java-Methode im data access object. Diese sehr einfache Methode fügt zwei integer-Werte in die Datenbank.

public void saveHourMin(int hour, int min) throws SQLException{
psInsert.setInt(1, hour);
psInsert.setInt(2, min);
psInsert.executeUpdate();
}

Sollte diese Methode, oder, allgemein gesprochen, alle DAO-Methode, eine exception werfen, wenn SQLException geworfen wird, oder sollte es abfangen und protokollieren die Ausnahme, dann informieren des Benutzers über return-code? Das ist der richtige Ansatz für eine Anwendung mit Spring?

  • Gibt es keinen vereinbarten "best practice" für diese.
  • Da bin ich mir sicher. Aber ich bin neu in diesem und ich brauche, um ein Bild zu bekommen, wie Sie zu lösen diese Situationen.
  • Eigentlich die gängige Praxis für den Umgang DAO-Ausnahmen ist das einwickeln von Ihnen in einigen custom DAO exception-Klassen. Lesen Sie diese sehr gute und beliebte tutorial von BalusC, die unter anderem beschreibt, DAO Ausnahmebehandlung und andere gute Praktiken: DAO-tutorial - der data layer
InformationsquelleAutor Artegon | 2013-03-05
  1. 5

    Kann man nicht zählen, auf die Anrufer konsequent überprüfen Sie die return-codes, sind Sie besser dran, eine Ausnahme zu werfen.

    Wenn Sie SQLException werfen, dann ist das eine Sauerei sein, werden Sie wahrscheinlich am Ende mit höheren Schichten, entweder indem Sie "throws Exception" in jeder Methode, oder einfach nur Essen Ausnahmen. Weder das eine dieser alternativen sind gut.

    Den Weg, der Frühling kommt, dann liefert es eine Ausnahme übersetzer, die dauert in der ursprünglichen SQLException und wirft eine Unterklasse von RuntimeException, die beinhaltet das original SQLException als eine Ursache und die zu geben versucht, so viel Informationen über den Fehler wie möglich, einschließlich der Verwendung von vendor-Fehler-codes zu entscheiden, welche konkrete Unterklasse zu werfen.
    Wenn Sie nutzen jede Feder ist jdbcTemplates dann bekommen Sie die Ausnahme-übersetzung-Funktionalität, so dass Sie nicht brauchen, um jede exception fangen oder werfen in Ihrem data access objects.

    Wenn Sie nicht möchten, zu verwenden, Frühjahr, können Sie fangen die SQLException innerhalb des DAO, und werfen einer RuntimeException, einschließlich der ursprünglichen SQLException als Ursache. Es gibt nichts, was Sie tun können, über das die meisten SQLExceptions, Sie wollen einfach nur fail fast und bekommen die Ausnahme protokolliert.

    InformationsquelleAutor Nathan Hughes
  2. 1

    Ich würde sagen Nein. Fangen Sie die SQLException und dann werfen einer RuntimeException oder, wenn die Nachkommen. Sie wollen nicht zu belasten Ihre Anwendung mit Datenzugriff Ausnahmen. Sie sollten nicht zu fangen, SQLExceptions in der GUI-Schicht zum Beispiel. Ich würde nicht eine Anwendung erstellen, basierend auf die return-codes entweder.

    Durch das werfen einer RuntimeException Sie nicht zwingen, den Anrufer zu fangen, entweder.

    InformationsquelleAutor LuckyLuke
  3. 1

    Ich würde erstellen Sie eine neue Ausnahme genannt DAOException, die NICHT eine RuntimeException, und zwingen den Anwender der Methode, um solche Ausnahmen, die eventuell mit einem enum als Mitglied der DAOException, die die Ausnahme beschreibt (evtl. mit Zusatz der eigentliche exception-innen, die als interne Ausnahme).

    So einer ausgelösten Ausnahme könnte wie folgt Aussehen: 

    new DAOException(DAOException.TYPE.SQLE, e)

    und die Methode saveHourMin wirft DAOException.

    Diese Weise, wenn Sie haben alle Arten von Problemen, es ist alles unter die gleiche Art von Ausnahme, und Sie nicht haben, um verschiedene.

    Dem Grund schlage ich vor, eine Allgemeine Ausnahme und nicht zur Laufzeit ist, weil ich nicht wollen, dass es optional zu handhaben ist die Ausnahme. Wem diese Methode aufruft, muss sich der Tatsache bewusst sein, dass so ein problem auftreten kann und zur entsprechenden Handhabung (auch wenn das bedeutet, dass das werfen eine neue RuntimeException, Gott bewahre, aber jetzt ist es bis zu Ihnen und es ist Ihre Entscheidung). Als Allgemeine Faustregel würde ich vermeiden, mit RuntimeExceptions, weil Sie den Ausführungspfad unklar ("wahrscheinlich wird jemand erwischen irgendwo die Ausführung Weg oder es tötet die app, so it 's ok to let it go" hört sich gar nicht gut an mir).

    InformationsquelleAutor TheZuck
Schreibe einen Kommentar