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

Die Verwendung einer Ausnahme ist in manchen Fällen eine schlechte Idee (insbesondere beim Schreiben eines Servers). Sie würden zwei Varianten der Methode benötigen. Sehen Sie sich auch die Wörterbuchklasse an, um einen Hinweis darauf zu erhalten, was Sie tun sollten.

// NB:  A bool is the return value. 
//      This makes it possible to put this beast in if statements.
public bool TryCalculatePoint(... out Point result) { }

public Point CalculatePoint(...)
{
   Point result;
   if(!TryCalculatePoint(... out result))
       throw new BogusPointException();
   return result;
}

Das Beste aus beiden Welten!

Answer 2

Das bool TrySomething() ist zumindest eine Übung, die für die Parse-Methoden von .net gut funktioniert, aber ich glaube nicht, dass ich sie im Allgemeinen mag.

Das Auslösen einer Ausnahme ist oft eine gute Sache, obwohl es nicht für Situationen verwendet werden sollte, die man in vielen normalen Situationen erwarten würde, und es ist mit Leistungseinbußen verbunden.

Null zurückzugeben, wenn möglich, ist in den meisten Fällen in Ordnung, wenn man keine Ausnahme will.

Allerdings - Ihr Ansatz ist etwas prozedural - wie wäre es, wenn Sie so etwas wie eine PointCalculator-Klasse erstellen und die erforderlichen Daten als Parameter in den Konstruktor aufnehmen? Dann rufen Sie CalculatePoint auf und greifen über Eigenschaften auf das Ergebnis zu (separate Eigenschaften für Point und für Success).

Answer 3

Sie wollen keine Ausnahmen auslösen, wenn etwas Erwartetes passiert, wie @Kevin sagte, sind Ausnahmen für Ausnahmefälle.

Sie sollten etwas zurückgeben, das für den "Fehler" erwartet wird, im Allgemeinen ist null meine Wahl der schlechten Rückgabe.

Die Dokumentation zu Ihrer Methode sollte die Benutzer darüber informieren, was sie erwartet, wenn die Daten rechnet nicht .

Answer 4

Wir haben einmal ein ganzes Framework geschrieben, bei dem alle öffentlichen Methoden entweder true (erfolgreich ausgeführt) oder false (Fehler aufgetreten) zurückgaben. Wenn wir einen Wert zurückgeben mussten, verwendeten wir Ausgabeparameter. Entgegen der landläufigen Meinung hat diese Art der Programmierung tatsächlich einen Großteil unseres Codes vereinfacht.

Answer 5

Nun, mit Point können Sie Point.Empty als Rückgabewert im Falle eines Fehlers zurücksenden. Nun, alles, was dies wirklich tut, ist ein Punkt mit 0 für den X- und Y-Wert zurückgeben, so dass, wenn das ein gültiger Rückgabewert sein kann, würde ich bleiben weg von dem, aber wenn Ihre Methode wird nie einen (0,0) Punkt zurück, dann können Sie das verwenden.