Wie, um anzuzeigen, dass ein Verfahren nicht erfolgreich war
https://stackoverflow.com/questions/161822
-
03-07-2019 - |
italiano
english
français
española
中国
日本の
العربية
Deutsch
한국어
Português
RussianFrage
ich mehrere ähnliche Verfahren haben, sagen zum Beispiel. CalculatePoint (...) und CalculateListOfPoints (...). Gelegentlich kann sie nicht gelingen, und muß diese den Anrufer anzuzeigen. Für CalculateListOfPoints, die eine generische Liste zurückgibt, könnte ich eine leere Liste zurück und bedürfen der Anrufer dies zu überprüfen; jedoch Point ist ein Werttyp und so kann ich nicht null dort zurück.
Im Idealfall würde ich die Methoden gerne ‚aussehen‘ ähnlich; Eine Lösung könnte sein, sie zu definieren
public Point CalculatePoint(... out Boolean boSuccess);
public List<Point> CalculateListOfPoints(... out Boolean boSuccess);
oder alternativ einen Punkt zurück? für CalculatePoint und null zurück Fehler anzuzeigen. Das würde bedeuten, der mit dem Nicht-Nullable Type werfen zurück, obwohl, die übermäßigen scheint.
Ein anderer Weg wäre die Boolesche boSuccess zurückzukehren, hat das Ergebnis (Punkt oder List) als ‚out‘ Parameter, und nennt sie TryToCalculatePoint oder etwas ...
Was ist Best Practice?
Edit: Ich möchte nicht, Ausnahmen für die Ablaufsteuerung verwenden! Ein Fehler wird manchmal erwartet.
Lösung
Ich persönlich denke, ich die gleiche Idee wie TryParse verwenden würde (): ein out-Parameter zur Ausgabe des reale Wert verwendet wird, und ein boolean Rückkehr anzeigt, ob der Anruf erfolgreich war oder nicht
public bool CalculatePoint(... out Point result);
Ich bin kein Fan von mit Ausnahme für „normales“ Verhalten.
(wenn Sie die Funktion nicht arbeitet für einige Einträge erwarten)Andere Tipps
Warum würden sie scheitern? Wenn es wegen etwas ist, hat der Anrufer getan (das heißt die Argumente zur Verfügung gestellt), dann wirft Argument ist durchaus angemessen. Ein Versuch [...] Verfahren, das die Ausnahme vermeidet, ist in Ordnung.
Ich denke, es ist eine gute Idee, um die Version zu schaffen, die allerdings eine Ausnahme auslöst, so dass Anrufer, die erwarten, dass sie immer eine gute Daten liefern, wird eine entsprechend starke Botschaft (dh eine Ausnahme) erhalten, wenn sie jemals falsch.
Eine weitere Alternative ist eine Ausnahme zu werfen. Allerdings Sie in der Regel nur wollen Ausnahmen werfen in „Ausnahmefällen“.
Wenn die Fehlerfälle sind häufig (und nicht außergewöhnlich), dann haben Sie bereits aus Ihren beiden Optionen aufgeführt. Bearbeiten : Es kann eine Konvention in Ihrem Projekt sein, wie, wie solche nicht-Ausnahmefälle zu behandeln (ob ein Erfolg oder das Objekt zurückgeben soll). Wenn es keine bestehende Konvention ist, dann bin ich mit lucasbfr und schlage vor, Sie Erfolg zurückkehren (die mit übereinstimmt, wie TryParse (...) ist so konzipiert).
Wenn der Fehler aus einem bestimmten Grunde ist dann denke ich, es ist ok null zurückzukehren, oder Bool und haben einen out-Parameter. Wenn Sie jedoch unabhängig von dem Ausfall null zurück, dann empfehle ich es nicht. Ausnahmen bieten eine breite Palette von Informationen, einschließlich der Grund, warum etwas fehlgeschlagen ist, wenn alles, was Sie zurückbekommen eine Null, dann ist, wie Sie wissen, ob seine weil die Daten falsch sind, können Sie aus dem Speicher oder eine andere seltsame Verhalten lief haben.
Auch in .net die TryParse hat einen Parse Bruder, so dass Sie die Ausnahme erhalten können, wenn Sie wollen.
Wenn ich ein TrySomething Verfahren bereitgestellt ich auch ein Etwas Verfahren bieten würde, die eine Ausnahme im Fall des Scheiterns warf. Dann liegt es an den Aufrufer zurück.
Das Modell, das ich verwendet habe, ist die gleiche MS verwendet, um mit den TryParse Methoden der verschiedenen Klassen.
Ihr Original-Code:
public Punkt CalculatePoint (... out Boolean boSuccess);
public List CalculateListOfPoints (... out Boolean boSuccess);
würde sich in
public bool CalculatePoint (... (oder ref) Punkt CalculatedValue);
public bool CalculateListOfPoints (... (oder ref) Liste CalculatedValues);
Im Grunde machen Sie den Erfolg / Misserfolg den Rückgabewert.
Zusammenfassend gibt es ein paar Ansätze sind Sie ergreifen können:
- Wenn der Rückgabetyp ein Wert-Typ, wie Punkt ist, die Nullable-Funktion von C # und einen Punkt zurückkommen? (Auch bekannt als Nullable), auf diese Weise Sie noch null auf einem Fehler zurückkehren
- eine Ausnahme ausgelöst, wenn ein Fehler ist. Die ganze Argument / Diskussion darüber, was ist und was nicht „außergewöhnlich“ ist ein strittiger Punkt, es ist Ihr API, Sie entscheiden, was außergewöhnliches Verhalten ist.
- Nehmen Sie ein Modell ähnlich dem von Microsoft in den Basistypen wie Int32 implementiert, bieten eine CalculatePoint und TryCalculatePoint (Int32.Parse und Int32.TryParse) und haben einen Wurf und eine Rückkehr ein Bool.
- Gibt eine generische Struktur von Ihren Methoden, die zwei Eigenschaften, bool Success und GenericType Wert.
Je nach Szenario I sind in der Regel eine Kombination von Rückkehr null oder werfen eine Ausnahme zu verwenden, da sie „saubersten“ scheinen mich und passen am besten mit der bestehenden Code-Basis bei der Firma für die ich arbeite. Also meine persönliche Bestleistung Praxis wäre Ansätze 1 und 2.
Es hängt vor allem von dem Verhalten der Methoden und deren Nutzung.
Wenn ein Fehler ist üblich und unkritische, dann haben Ihre Methoden geben eine Bedingung, die anzeigt ihren Erfolg und verwenden Sie einen Out-Parameter das Ergebnis zu vermitteln. einen Schlüssel in einem Hash aufzublicken, versuchen, Daten auf einem nicht blockierenden Socket zu lesen, wenn keine Daten verfügbar sind, fallen alle diese Beispiele in dieser Kategorie.
Wenn ein Fehler unerwartet ist, kehrt das Ergebnis direkt und vermitteln Fehler mit Ausnahmen. Das Öffnen einer Datei schreibgeschützt ist, zu einem TCP-Server zu verbinden, sind gute Kandidaten.
Und manchmal in beiden Richtungen Sinn machen ...
Zurück Point.Empty . Es ist eine .NET-Design Rüttler ein spezielles Feld zurückzukehren, wenn Sie überprüfen möchten, ob Strukturerstellung erfolgreich war. Vermeiden Sie aus Parameter, wenn Sie können.
public static readonly Point Empty
Ein Muster, das ich das Experimentieren mit zurückkehrt ein Vielleicht . Es hat die Semantik des TryParse Muster, aber eine ähnliche Signatur auf das Null-Return-on-Fehlermuster.
Ich bin noch nicht überzeugt, die ein oder andere, aber ich biete es für Ihre kollektive Überlegung. Es hat den Vorteil, nicht eine Variable definiert vor dem Methodenaufruf erfordert die Out-Parameter an der Aufrufstelle des Verfahrens zu halten. Es könnte auch mit einem Fehler erweitert werden oder Nachrichten Sammlung den Grund für den Fehler anzuzeigen.
Die Vielleicht Klasse etwas wie folgt aussieht:
/// <summary>
/// Represents the return value from an operation that might fail
/// </summary>
/// <typeparam name="T"></typeparam>
public struct Maybe<T>
{
T _value;
bool _hasValue;
public Maybe(T value)
{
_value = value;
_hasValue = true;
}
public Maybe()
{
_hasValue = false;
_value = default(T);
}
public bool Success
{
get { return _hasValue; }
}
public T Value
{
get
{ // could throw an exception if _hasValue is false
return _value;
}
}
}
Ich würde sagen, Best Practice ist ein Rückgabewert bedeutet Erfolg, und ein Ausnahme bedeutet Versagen.
ich keinen Grund, in den Beispielen sehen Sie, sofern Sie nicht a href werden mit <= „http://www.c-sharpcorner.com/UploadFile/rajeshvs/ExceptionHandlinginCSharp11282005051444AM/ExceptionHandlinginCSharp.aspx“ rel = "nofollow noreferrer "> Ausnahmen im Fall eines Ausfalls.
eine Ausnahme zu verwenden ist eine schlechte Idee, in einigen Fällen (vor allem, wenn Sie einen Server zu schreiben). Sie würden zwei Varianten des Verfahrens müssen. Schauen Sie auch in der Wörterbuch-Klasse für einen Hinweis darauf, was Sie tun sollen.
// 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!
Der Bool TrySomething () ist zumindest eine Praxis, die für .net des Parse-Methoden funktioniert ok, aber ich glaube nicht, dass ich es im Allgemeinen mag.
Werfen eine Ausnahme ist oft eine gute Sache, wenn es nicht für Situationen verwendet werden, sollten Sie erwarten würden in vielen normalen Situationen geschehen, und es hat eine zugehörigen Leistungskosten.
null zurückkehrend, wenn möglich, in den meisten Fällen in Ordnung ist, wenn man nicht eine Ausnahme möchten.
Jedoch - Ihr Ansatz ein bisschen Verfahren ist - was so etwas wie eine PointCalculator Klasse über das Erstellen - die erforderlichen Daten als Parameter im Konstruktor zu nehmen? Dann rufen Sie CalculatePoint Sie darauf und auf das Ergebnis durch Eigenschaften (getrennte Eigenschaften für Punkt und für den Erfolg).
Sie wollen nicht sein, Ausnahmen zu werfen, wenn es etwas zu erwarten geschieht, wie @ Kevin angegeben Ausnahmen für Ausnahmefälle sind.
Sie sollten etwas zurückgeben, die für das ‚Versagen‘, in der Regel null ist meine Wahl der schlechten Rendite zu erwarten ist.
Die Dokumentation für Ihre Methode sollte die Benutzer informieren, was zu erwarten, wenn die Daten berechnet nicht .
Wir haben einmal geschrieben einen ganzen Rahmen, in dem alle öffentlichen Methoden entweder zurückgegeben true (erfolgreich ausgeführt) oder falsch (ein Fehler aufgetreten ist). Wenn wir brauchten einen Wert zurückgeben wir Ausgabeparameter verwendet. Entgegen der landläufigen Meinung, diese Art der Programmierung vereinfacht tatsächlich viele unserer Code.
Nun mit Point, können Sie Point.Empty als Rückgabewert im Fehlerfall zurückzuschicken. Nun all dies wirklich tut, ist ein Punkt zurück mit 0 für die X- und Y-Wert, so dass, wenn eine gültige Rückgabewert sein kann, würde ich bleiben weg von diesem, aber wenn Ihre Methode wird nie ein (0,0) Punkt zurück , dann können Sie diese verwenden.
Es tut uns Leid, ich habe gerade die Nullable-Typ erinnert, sollten Sie sich darum kümmern. Ich bin nicht sicher, was der Aufwand allerdings ist.
