Wird null zurückgeben, nach der die Ausnahme abgefangen ist schlechtes design
Ich komme immer auf das gleiche problem, dass, wenn eine Ausnahme aufgefangen wird in einer Funktion mit einem non-void-Rückgabewert, weiß ich nicht, was Sie zurück. Der folgende Codeausschnitt veranschaulicht mein problem.
public Object getObject(){
try{
...
return object;
}
catch(Exception e){
//I have to return something here but what??
return null; //is this a bad design??
}
}
Also meine Fragen sind:
- Wird null zurückgeben, schlechtes design?
- Wenn dem so ist, was gesehen wird als eine saubere Lösung??
Dank.
- Ich nehme an, Sie wissen das, aber es ist fast immer eine schlechte Idee
catch(Exception e)
. Wenn der code im try {} - block ist gut geschrieben, Sie sollten eine gute Idee, was Ausnahme zu werfen, und Sie können fangen Sie einfach eine.
Du musst angemeldet sein, um einen Kommentar abzugeben.
Ich würde sagen, nicht die Ausnahme abfangen, wenn Sie können nicht wirklich damit umgehen. Und Protokollierung gilt nicht als Umgang mit einem Fehler. Besser, Blase es auf jemanden zu, kann durch das werfen der Ausnahme.
Wenn Sie müssen einen Wert zurückgeben, und null ist die einzige vernünftige Sache, es ist nichts falsch mit, dass. Nur Dokument und machen es den Nutzern klar, was getan werden sollte. Ein unit-test zeigt, dass die Ausnahme ausgelöst wird, so dass der Entwickler kommt, nachdem Sie sehen können, was das idiom angenommen werden muss. Werde es auch testen, um sicherzustellen, dass Ihr code löst die Ausnahme aus, wenn es sollte.
Wenn Sie nicht wissen, was zurück, dann bedeutet es, dass Sie nicht wissen, wie zu handhaben die Ausnahme. In diesem Fall re-throw es. Bitte, nicht schlucken es stillschweigend. Und bitte, nicht zurück
null
, die Sie nicht erzwingen möchten, dass der Anrufer, der den code zu schreiben:Dies ist IMHO ein schlechtes design, ich persönlich hasse es, zu schreiben, die null-Prüfungen (viele Male, wird null verwendet, wo eine exception geworfen werden sollte statt).
So, wie ich sagte, fügen Sie ein
throws
- Klausel der Methode und entweder Total remote try/catch-block oder halten Sie die try/catch, ob es Sinn macht (zum Beispiel, wenn Sie benötigen, um mit einigen Ausnahmen) und rethrow die Ausnahme ist, oder wickeln Sie es in eine benutzerdefinierte Ausnahme.Fragen
Vor allem ich möchte nicht auf null zurück. Das ist etwas, dass der Benutzer Sie ausdrücklich daran erinnern zu handhaben als ein besonderer Fall (es sei denn, Sie erwarten eine null - ist das dokumentiert). Wenn Sie Glück haben werden Sie Rücksicht es sofort und leiden einen Fehler. Wenn Sie Pech haben werden Sie stecken es in eine Sammlung und leiden unter dem gleichen problem später auf.
Ich glaube, Sie haben zwei Optionen:
Folge ich einem coding-Stil, in dem ich selten eine null zurück. Falls/wenn ich das mache, das ist explizit dokumentiert, so dass Kunden können erfüllt.
Ausnahmen bezeichnen außergewöhnliche Fällen. Angenommen, Ihr code sollte ein Objekt zurückgeben, etwas muss Weg falsch auf dem Weg (Netzwerk-error, out of memory, wer weiß?) und deshalb sollten Sie nicht nur Stille es von null zurückgeben.
Jedoch in vielen Fällen, Sie können finden Sie in der Dokumentation, dass eine Methode eine null zurück, wenn dieser Zustand Auftritt. Die Kunde von dieser Klasse können dann zählen Sie auf dieses Verhalten und handle ein null zurückgegeben, nichts schlechtes über das. Siehe, in diesem zweiten Anwendungsbeispiel, es ist kein außergewöhnlicher Fall - die Klasse ist so konzipiert null zurück, unter bestimmten Bedingungen - und daher ist es völlig in Ordnung, so zu machen (aber tun Sie das Dokument, das beabsichtigte Verhalten).
So, am Ende des Tages, es hängt wirklich davon ab, ob Sie nicht das Objekt zurückgeben, weil Sie etwas außergewöhnliches in Ihren Weg, oder Sie haben einfach keine Objekt wieder, und es ist absolut in Ordnung.
Ausnahmen sollten immer abgefangen werden, indem der controller in die Ende.
Die übergabe eines <null> bis auf den controller macht keinen Sinn.
Besser werfen/wieder der ursprünglichen Ausnahme in den stack.
Ich mag die Antworten legen nahe, dass eine Ausnahme geworfen, aber das bedeutet, dass Sie entwickelt haben, exception-handling in die Architektur Ihrer software.
Fehlerbehandlung in der Regel hat 3 Teile: Erkennung, Meldung und Erholung. Meiner Erfahrung nach, die Fehler fallen in Klassen, die von der schwere (das folgende ist eine gekürzte Liste):
Ihre Fehler klassifiziert werden sollten und die Handhabung sollte so generisch und konsequent wie möglich. Wenn Sie haben, zu betrachten, zu behandeln, wie jeden Fehler, jedes mal, wenn Sie schreiben einige neue Codes, die Sie nicht haben eine effektive Fehlerbehandlung Strategie für Ihre software. Ich mag, um eine reporting-Funktion, die initiiert die Interaktion der Nutzer sollte die Fortsetzung davon abhängig sein, ob die Wahl des Benutzers.
Die Antwort auf die Frage, ob eine null zurück (ein gut getragen Muster, wenn ich jemals eines gesehen), dann ist davon abhängig, welche Funktion protokolliert den Fehler, was kann/muss der Aufrufer tun, wenn die Funktion schlägt fehl und gibt null, und ob oder auch nicht die schwere des Fehlers bestimmt zusätzliche Handhabung.
Es ist Ihr code, und es ist keine schlechte Lösung. Aber wenn du deinen code, den Sie Durfte nicht zu verwenden, da es werfen kann unerwartete Ausnahme (wie eine nullpointer).
Können Sie natürlich auch
geben kann, um übergeordnete Funktion verwertbaren Informationen und wird Sie warnen, dass etwas schlimmes passieren kann.
Grundsätzlich würde ich ditto auf Duffymo, mit einem leichten Zusatz:
Als er sagt, wenn Ihr Gesprächspartner nicht die Ausnahme behandeln und erholen, dann nicht die Ausnahme abfangen. Lassen Sie eine höhere Ebene der Funktion fangen.
Wenn der Anrufer braucht, um etwas zu tun, sollte aber dann entsprechend sterben selbst, nur rethrow die Ausnahme. Wie:
Könnte man auch neu Verpacken Ausnahme, wie ...
Dies ist, warum so viel java-code wird aufgebläht mit
if (x!=null) {...}
Klauseln. Nicht erstellen Sie Ihre eigenen Null-Pointer-Exceptions.Ich würde sagen, es ist eine schlechte Praxis. Wenn
null
empfangen wird, wie weiß ich, ob dasobject
ist nicht vorhanden oder ein Fehler passiert ist?Mein Vorschlag ist
Wenn der Rückgabetyp ist ein Objekt, es ist bis zu Sie null zurück, je nach Szenario. Aber nie und nimmer schlucken eine Ausnahme und wird NULL zurückgegeben.
Auch wenn Sie NULL zurückgeben in jedem Szenario, sicherzustellen, dass dies ist dokumentiert in der Methode.
Als Josha Blooch sagt in dem Buch "Effektive Java", die null ist ein Schlüsselwort von Java.
Dieses Wort bezeichnet einen Speicherbereich, ohne Zeiger zu beliebigen anderen Speicher-Ort: meiner Meinung nach ist es besser, den Code mit der Trennung von Verhalten über die funktionale Domäne (Beispiel: Sie warten, für ein Objekt der Art Eine, jedoch erhalten Sie ein Objekt der Art B) und das Verhalten des low-level-Domäne (Beispiel: Ausschaltung der Speicher).
In deinem Beispiel würde ich ändern code :
Nachteil ist das erstellen eines kompletten Objektes wird bei jedem Aufruf von getObject() (dann in der situation, wo das Objekt zurückgegeben wird, nicht Lesen oder schreiben).
Aber ich bevorzuge, um den gleichen Gegenstand nutzlos als ein NullPointerException, weil manchmal diese Ausnahme ist sehr schwer zu beheben ist.
Einige Gedanken zum Umgang mit Ausnahmen
Ob null zurückgeben würde, gut oder schlecht sein design richtet sich auf die Ausnahme an und wo dieses snippet ist in Ihrem system.
Wenn die Ausnahme eine NullPointerException Sie wahrscheinlich gelten, wird der catch-block etwas aufdringlich (wie flow-control).
Wenn es so etwas wie IOException, und Sie können nicht tun, was gegen das Grund sollten Sie werfen der Exception an den controller.
Wenn der controller, der die Fassade einer Komponente, die er, zu übersetzen Ausnahme der gut dokumentierten Komponenten-spezifischen Satz von möglichen Ausnahmen, die auftreten können, an die Schnittstelle. Und für detaillierte Informationen sollten Sie auch die ursprüngliche Ausnahme als geschachtelte Ausnahme.