Wie kann man angeben, dass eine Methode erfolglos war?

Question

Ich habe mehrere ähnliche Methoden, z.B. CalculatePoint(...) und CalculateListOfPoints(...). Gelegentlich kann es vorkommen, dass sie nicht erfolgreich sind, und dies muss dem Aufrufer angezeigt werden. Für CalculateListOfPoints, das eine generische Liste zurückgibt, könnte ich eine leere Liste zurückgeben und den Aufrufer auffordern, dies zu überprüfen; Point ist jedoch ein Werttyp und daher kann ich dort nicht null zurückgeben.

Im Idealfall möchte ich, dass die Methoden ähnlich "aussehen"; eine Lösung könnte darin bestehen, sie als

public Point CalculatePoint(... out Boolean boSuccess);
public List<Point> CalculateListOfPoints(... out Boolean boSuccess);

oder alternativ einen Punkt? für CalculatePoint zurückgeben, und null zurückgeben, um einen Fehler anzuzeigen. Das würde bedeuten, dass man zurück zum nicht-nullbaren Typ casten muss, was übertrieben erscheint.

Eine andere Möglichkeit wäre, den Boolean boSuccess zurückzugeben, das Ergebnis (Punkt oder Liste) als 'out'-Parameter zu haben und sie TryToCalculatePoint oder so zu nennen...

Was ist die beste Praxis?

Bearbeiten: Ich möchte keine Ausnahmen für die Flusskontrolle verwenden! Ein Fehlschlag wird manchmal erwartet.

Answer 1

Persönlich denke ich, dass ich die gleiche Idee wie TryParse() verwenden würde: einen out-Parameter verwenden, um den tatsächlichen Wert auszugeben, und einen booleschen Wert zurückgeben, der angibt, ob der Aufruf erfolgreich war oder nicht

public bool CalculatePoint(... out Point result);

Ich bin kein Fan davon, Ausnahmen für "normales" Verhalten zu verwenden (wenn Sie erwarten, dass die Funktion bei einigen Einträgen nicht funktioniert).

Answer 2

Warum sollten sie scheitern? Wenn es wegen etwas ist, das der Aufrufer getan hat (d.h. die angegebenen Argumente), dann ist das Auslösen einer ArgumentException völlig angemessen. Eine Try[...] Methode, die die Ausnahme vermeidet, ist in Ordnung.

Ich denke, es ist eine gute Idee, die Version bereitzustellen, die eine Ausnahme auslöst, so dass Aufrufer, die erwarten, dass sie immer gute Daten liefern, eine entsprechend starke Nachricht (d.h. eine Ausnahme) erhalten, wenn sie sich jemals irren.

Answer 3

Eine andere Alternative ist das Auslösen einer Ausnahme. Allerdings sollten Sie Ausnahmen im Allgemeinen nur in "Ausnahmefällen" auslösen.

Wenn es sich um häufige (und nicht um außergewöhnliche) Fehler handelt, haben Sie bereits Ihre beiden Möglichkeiten aufgezählt. EDIT : Möglicherweise gibt es in Ihrem Projekt eine Konvention, wie solche nicht außergewöhnlichen Fälle zu behandeln sind (ob man Erfolg oder das Objekt zurückgeben sollte). Wenn es keine Konvention gibt, dann stimme ich mit lucasbfr überein und schlage vor, dass Sie Erfolg zurückgeben (was damit übereinstimmt, wie TryParse(...) konzipiert ist).

Answer 4

Wenn der Fehler aus einem bestimmten Grund ist, dann denke ich, dass es ok ist, null oder bool zurückzugeben und einen out-Parameter zu haben. Wenn Sie jedoch unabhängig vom Fehler null zurückgeben, empfehle ich dies nicht. Ausnahmen bieten eine Fülle von Informationen, einschließlich der Grund, warum etwas fehlgeschlagen ist, wenn alles, was Sie zurück ist eine Null dann wie wissen Sie, wenn seine, weil die Daten falsch sind, Sie haben aus dem Speicher oder einige andere seltsame Verhalten lief.

Sogar in .net hat TryParse einen Parse-Bruder, so dass Sie die Ausnahme erhalten können, wenn Sie wollen.

Wenn ich eine TrySomething-Methode bereitstellen würde, würde ich auch eine Something-Methode bereitstellen, die im Falle eines Fehlschlags eine Ausnahme auslöst. Dann hängt es vom Aufrufer ab.

Answer 5

Das hängt vor allem vom Verhalten Ihrer Methoden und deren Verwendung ab.

Wenn Fehler häufig und unkritisch sind, sollten Ihre Methoden einen booleschen Wert zurückgeben, der den Erfolg anzeigt, und einen out-Parameter verwenden, um das Ergebnis zu übermitteln. Das Nachschlagen eines Schlüssels in einem Hash, der Versuch, Daten über einen nicht blockierenden Socket zu lesen, wenn keine Daten verfügbar sind - all diese Beispiele fallen in diese Kategorie.

Bei unerwarteten Fehlern geben Sie direkt das Ergebnis zurück und melden Fehler mit Ausnahmen. Das Öffnen einer Datei mit Lesezugriff oder die Verbindung zu einem TCP-Server sind gute Kandidaten.

Und manchmal sind beide Wege sinnvoll...