2009-07-16 2 views
2

In der Dokumentation für isValid(int) von java.sql.Connection (eine Schnittstelle):Wie interpretierst du diesen Teil von Javadoc?

http://java.sun.com/javase/6/docs/api/java/sql/Connection.html#isValid(int)

es heißt, dass es eine „SQLException, wenn der Wert geliefert für timeout ist weniger als 0“ werfen.

Sollte Implementierer liest dies als „SQLException, wenn und nur wenn der für timeout geliefert Wert kleiner als 0“ oder sind sie frei zu ihm für eine Reihe von anderen Gründen zu werfen?

EDIT: Ich denke, ich bin verwirrt/genervt, warum sie IllegalArgumentException nicht verwendet haben. Ich erwarte SQLException Dinge wie "die Datenbank scheint geschmolzen zu sein", nicht "Sie haben ein grundlegendes Missverständnis dessen, was dieses Argument ist".

+0

Warum testen Sie es nicht einfach? oder sehen Sie sich den Quellcode an? –

+0

Es ist eine Schnittstelle – looeeese

+1

@Bishiboosh, im Allgemeinen JDBC-Treiber ihren Quellcode nicht offen legen, und trotzdem ist es eine Spezifikation Frage, so dass selbst wenn eine gegebene Implementierung die Ausnahme aus irgendeinem anderen Grund nicht wirft, bedeutet das nicht das andere wird nicht. – Yishai

Antwort

3

Ich würde es nicht als "wenn und nur wenn" lesen (obwohl das wahrscheinlich der Fall ist). Wenn die timeout kleiner als 0 ist, wird definitiv eine Ausnahme ausgelöst, aber das bedeutet nicht notwendigerweise bedeutet, dass es in anderen Fällen nicht geworfen wird. Ich denke, die Entwickler beabsichtigten es als "wenn und nur wenn" zu lesen, aber ich spekuliere gerade so kann man nicht wirklich sicher sein.

+0

Ich kann mir nicht vorstellen, dass eine SQLException in anderen Kontexten nützlich wäre. Jede andere Ausnahme sollte zu einem Rückgabewert von "false" führen. – james

2

Diese Methode prüft, ob das Timeout kleiner als 0 ist; Wenn dies der Fall ist, wird die Ausnahme ausgelöst. Es ist jedoch immer noch frei, eine unbeabsichtigte Ausnahme während der Ausführung des Algorithmus zu werfen.

Wenn Sie es überschreiben, sollten Sie sich als Ihre Oberklasse verhalten, nur mit einer anderen Implementierung. Aufgrund von Olymorphismus kann Ihre Unterklasse instanziiert werden, aber als Oberklasse referenziert werden. Wenn Sie daher eine Ausnahme aus einem Grund werfen, den die Oberklasse nicht dokumentiert, können Sie nur Verwirrung und möglicherweise fehlerhaften Code erzeugen.

0

ich würde es als Ihre frühere Interpretation interpretieren ("wenn und nur wenn"). Ich würde mir vorstellen, dass eine SQLException aus irgendeinem anderen Grund für den Anrufer nicht nützlich wäre. Wenn der isValid-Aufruf aus einem anderen Grund fehlschlägt, erscheint eine Antwortantwort von "false" am geeignetsten.

+0

es sei denn, es ist wirklich außergewöhnlich. Die Rückgabe von false ist eine schlechte Idee für die API. – geowa4

1

Ich denke, es ist ziemlich sicher davon ausgehen, dass „wenn der Wert für Timeout zugeführt wird, weniger als 0“ ist der einzige Fall, in dem ConnectionisValid wird eine SQLException werfen, aber ich glaube nicht, es ist sicher für jede Klasse zu übernehmen und Jede Methode im Allgemeinen, dass die dokumentierte Throws-Bedingung die einzige Bedingung ist, die zum Auslösen einer Ausnahme führt.

0

Ich verstehe völlig Ihre Frustration mit JDBC. Es scheint, als hätte das JDBC-Team nicht geglaubt, dass sie den Konventionen entsprechen müssten, die über den Rest der Java SE-Plattform eingeführt wurden.

Dies hat mich in der Vergangenheit viel Verwirrung verursacht, z. B. ihre Ausnahmebehandlung ist nicht so standard wie es sein könnte, wie Sie hingewiesen haben. Ich wünschte auch, dass SQLException eine Laufzeitausnahme wäre (oder zumindest Datenbank-bezogene Ausnahmehierarchien haben würde, eine überprüfte und eine nicht-überprüfte). Und zu guter Letzt ist meine größte Sorge, dass Indizes in JDBC 1 indiziert werden, wenn die Dinge im Rest von Java generell 0-indexiert sind.

In diesem Fall denke ich, dass Sie wahrscheinlich zu Recht "wenn und nur wenn" annehmen. Das heißt, versuchen Sie, Ihren eigenen Treiber zu implementieren? Wenn ja, welche anderen Ausnahmebedingungen erwarten Sie?

0

Ja, es sollte die Ausnahme werfen , wenn und nur wenn der Timeout-Wert kleiner als 0

Wenn es ein Problem mit der Verbindung, dann sollte die Methode falsch zurückzukehren.

0

Als Ganzes gelesen, ich lese das Javadoc zu sagen, dass, wenn die Verbindung nicht gültig ist (dh nicht geschlossen und nutzbar), oder wenn das Timeout überschritten wird es false zurückgibt.

Wenn jedoch bei der Abfrage der Datenbank über die Gültigkeit der Verbindung noch etwas schief geht, wird möglicherweise noch eine SQLException ausgelöst. (Sagen wir zum Beispiel, die Abfrage ist gegen eine erforderliche Systemtabelle der Datenbank, die fehlt, oder die Transaktion wird während der Prüfung zurückgesetzt).

Eine SQLException wird immer ausgelöst, wenn der Zeitüberschreitungswert kleiner als Null ist.

Das heißt, es gibt eine Menge Probleme mit (JDBC im Allgemeinen und) diese Spezifikation im Besonderen.

Was definiert eine ungültige Verbindung? Wenn ein Datenbankfehler ausgelöst wird, können wir wirklich sagen, dass wir nicht wissen, ob die Verbindung gültig ist. Es ist wahrscheinlich sowieso kaputt. Das einzige, was mir einfällt, ist, dass die Verbindung noch geschlossen werden muss, während "= = false" bedeutet, dass die Verbindung tot ist, also nicht geschlossen werden muss. Dies führt zum nächsten Problem:

Gültig ist nicht formell definiert. Es bedeutet nicht geschlossen und etwas anderes. Aber das etwas anderes ist irgendwie vage. Es sollte benutzbar sein, aber was, wenn es nicht geschlossen ist, aber nicht verwendbar?

Und schließlich, warum so eine negative Zahl so intolerant sein? Es ist genauso einfach zu sagen: Ein Wert von 0 oder weniger gibt an, dass eine Zeitüberschreitung nicht auf die Datenbankoperation angewendet wurde.

Und natürlich wurde die Spezifikation auf isClosed() nicht aktualisiert, um die neue isValid (int) -Methode zu erkennen.

Die JDBC API ist wirklich eine Travestie im Allgemeinen.

Auf der anderen Seite, wenn die Bedeutung ist , wenn und nur wenn, soll es gesagt hat, dass, und wenn SQLException kann nicht aus einem anderen Grunde geworfen wird, dann soll dies eine Runtime-Ausnahme (Illegal zum Beispiel), weil einen negativen Wert zu übergeben wäre nur ein Programmierfehler. Wenn SQLException andererseits aus anderen Gründen ausgelöst werden kann, ist es zumindest vertretbar, dass es sich nicht lohnt, eine separate Ausnahme einzuführen, wenn die geprüfte Ausnahme trotzdem behandelt werden muss. Ich bin mir nicht sicher, ob ich dem Argument zustimme, aber es könnte zumindest einen Vorteil haben. (Hinweis: Ich schreibe diesen letzten Absatz nicht als Beweis dafür, dass die Spezifikation nicht genau dann und nur dann zählt, wenn es das ist.)