Warum sind die Ausnahmen so schlecht für die Eingabeüberprüfung sein?

https://stackoverflow.com/questions/410558

03-07-2019
|

Frage

Ich verstehe, dass „Ausnahmen für Ausnahmefälle sind“ [a], aber neben nur wiederholt werden, über wieder, habe ich noch nie gefunden ein tatsächlicher Grund für diese Tatsache.

Ist, dass sie die Ausführung zu stoppen, macht es Sinn, dass Sie sie nicht wollen würde, für Normal bedingte Logik, aber warum nicht Eingabevalidierung?

Sagen Sie einer Schleife durch eine Gruppe von Eingängen sind und jede Ausnahme Gruppe fängt sie zusammen für Benutzerbenachrichtigung ... Ich sehe immer wieder, dass dies irgendwie „falsch“ ist, weil die Benutzer all fehlerhafte Eingabe der Zeit eingeben, aber dieser Punkt scheint basierend auf Semantik zu sein.

Der Eingang ist nicht, was erwartet wurde und daher ist außergewöhnlich. Auslösen einer Ausnahme erlaubt es mir, genau zu definieren, was wie StringValueTooLong falsch war oder oder IntegerValueTooLow oder InvalidDateValue oder was auch immer. Warum wird dies als falsch?

Die Alternative, eine Ausnahme zu werfen würde zu jeder Rückkehr (und sammelt schließlich) ein Fehlercode oder noch schlimmer ein Fehler Zeichenfolge. Dann würde es entweder direkt zeigt diese Fehlerstrings, oder die Fehlercodes analysieren und zeigt dann entsprechende Fehlermeldungen an den Benutzer. Wäre es nicht eine Ausnahme eines formbaren Fehlercode in Betracht gezogen werden? Warum eine separate Tabelle des Fehlercodes und Nachrichten erstellen, wenn diese mit Ausnahme Funktionalität verallgemeinert werden könnte bereits eingebaut in meine Sprache?

Auch dieser Artikel von Martin Fowler gefunden , wie solche Dinge zu handhaben - die Mitteilung Muster. Ich bin nicht sicher, wie ich das sehen als etwas anderes als Ausnahmen zu sein, dass die Ausführung nicht stoppen.

a:. Überall habe ich etwas über Ausnahmen lesen

--- --- Bearbeiten

Viele große Punkte gemacht worden. Ich habe auf die am meisten kommentierten und + 'd die guten Punkte, aber ich bin noch nicht ganz überzeugt.

ich meine nicht Ausnahmen, wie die richtigen Mittel zu befürworten Eingabevalidierung zu lösen, aber ich möchte gute Gründe finden, warum die Praxis so Übel angesehen wird, wenn es scheint, die meisten alternativen Lösungen nur Ausnahmen in der Verkleidung sind.

Lösung

diese Antworten lesen, finde ich es sehr hilfreich zu sagen: „Ausnahmen sollten nur für Ausnahmebedingungen verwendet werden“. Es stellt sich die ganze Frage, was ist ein „Ausnahmezustand“. Dies ist ein subjektiver Begriff, die beste Definition von denen „jede Bedingung, die Ihr normaler Logikfluss mit nicht umgehen“. Mit anderen Worten, ist eine außergewöhnliche Bedingung jede Bedingung, die Sie mit der Verwendung von Ausnahmen behandeln.

Ich bin fein mit, dass als eine Definition, weiß ich nicht, dass wir alle näher als ohnehin, dass bekommen. Aber Sie sollten wissen, dass das ist die Definition Sie verwenden.

Wenn Sie vorhaben, in einem bestimmten Fall gegen Ausnahmen zu argumentieren, müssen Sie erklären, wie das Universum von Bedingungen in „außergewöhnliche“ zu unterteilen und „nicht außergewöhnlich“.

In gewisser Hinsicht ist es ähnlich, die Frage zu beantworten, „wo die Grenzen zwischen Prozeduren sind?“ Die Antwort lautet: „Überall dort, wo Sie den Beginn und das Ende setzen“, und dann können wir über Faustregeln und verschiedene Stile zur Bestimmung wohin mit ihnen sprechen. Es gibt keine festen Regeln.

Andere Tipps

Ein Benutzer ‚schlecht‘ Eingabe Eingabe ist keine Ausnahme: Es ist zu erwarten,

Ausnahmen sollten nicht für die normalen Kontrollfluss verwendet werden.

In der Vergangenheit haben viele Autoren gesagt, dass Ausnahmen von Natur aus teuer sind. Jon Skeet hat gebloggt Gegensatz dazu (und erwähnte ein paar Mal in den Antworten hier auf SO), sagte, dass sie sind nicht so teuer wie berichtet (obwohl ich nicht befürworten würde sie in einer engen Schleife mit!)

Der wichtigste Grund dafür, sie zu benutzen ist ‚Absichtserklärung‘ das heißt, wenn Sie eine Fehlerbehandlung Block sehen Sie sofort die Ausnahmefälle sehen, die mit außerhalb der normalen Strömung behandelt werden.

Es gibt ein wichtig anderen Grund als die Erwähnten bereits:

Wenn Sie Ausnahmen nur für Ausnahmefälle können Sie mit der Debugger-Einstellung „stoppen, wenn Ausnahme ausgelöst wird,“ in Ihrem Debugger ausführen. Dies ist äußerst praktisch, weil Sie in den Debugger auf die genaue Linie ziehen, der das Problem verursacht. Mit dieser Funktion spart Ihnen eine Menge Zeit jeden Tag .

In C # ist dies möglich (und ich empfehle es von ganzem Herzen), vor allem, nachdem sie die TryParse Methoden zu alle Anzahl Klassen hinzugefügt. Im Allgemeinen keine der Standardbibliotheken erfordern oder verwenden Sie „schlechte“ Ausnahmebehandlung. Wenn ich eine C # Code-Basis nähern, die nicht dieser Norm geschrieben hat, habe ich immer am Ende es ausnahme free-for-regular Fällen Umwandlung, da die Stop-om-Wurf so wertvoll ist.

Im Firebug JavaScript-Debugger Sie dies auch tun können, vorausgesetzt, dass Ihre Bibliotheken Ausnahmen nicht schlecht verwenden.

Wenn ich Java-Programm, das ist nicht wirklich möglich, weil so viele Dinge verwendet Ausnahmen für nicht-Ausnahmefällen, viele der Standard-Java-Bibliotheken einschließlich. Also diese zeitsparende Funktion ist nicht wirklich für den Einsatz in Java. Ich glaube, dies zu überprüfen Ausnahmen zurückzuführen ist, aber ich werde beginnen nicht schimpfen darüber, wie sie böse sind.

Fehler und Ausnahmen - Was, Wann und Wo

Ausnahmen sollen Fehler melden, wodurch Code robuster. Um zu verstehen, wenn Ausnahmen zu verwenden, muss man zunächst verstehen, welche Fehler sind und was ist kein Fehler.

Eine Funktion ist eine Arbeitseinheit und Ausfälle sollten als Fehler oder auf andere Weise auf der Grundlage ihrer Auswirkungen auf die Funktionen angezeigt werden. Innerhalb einer Funktion f ist ein Fehler ein Fehler, wenn und nur wenn es f von der Erfüllung eines seiner Angerufenen Voraussetzungen verhindert, das Erreichen jeden < strong> f 's eigene Nachbedingungen , oder die Wiederherstellung jeden invariant , die für die Aufrechterhaltung strong> f Aktien Verantwortung <.

Es gibt drei Arten von Fehlern:

eine Bedingung, dass die Funktion von der Erfüllung einer Bedingung (beispielsweise eine Parameter Einschränkung) einer anderen Funktion verhindert, die aufgerufen werden muss;
eine Bedingung, dass die Funktion aus der Errichtung eines eigenen Nachbedingungen verhindert (beispielsweise einen gültigen Rückgabewertes Herstellung ist eine Nachbedingung); und
eine Bedingung, die die Funktion von Wiederherstellung eines invarianten verhindert, dass es für die Aufrechterhaltung verantwortlich ist. Dies ist eine besondere Art von Nachbedingung, die vor allem auf Funktionen Mitglied gilt. Ein wesentlicher Nachbedingung eines jeden nicht-privaten Member-Funktion ist, dass es seine Klasse Invarianten wieder herstellen müssen.

Eine andere Bedingung ist nicht ein Fehler und sollte nicht als Fehler gemeldet werden.

Warum sind Ausnahmen der so schlecht für die Gültigkeitsprüfung sein?

Ich denke, es wegen eines etwas zweideutig Verständnis von „Eingang“ ist entweder Bedeutung Eingang einer Funktion oder Wert eines Feldes , wobei letztere should't werfen eine Ausnahme, wenn sie Teil einer fehlerhaften Funktion ist.

Ich denke, der Unterschied auf dem Vertrag der jeweiligen Klasse abhängt, d.

Für Code, der gemeint ist, mit Benutzereingaben zu behandeln, und das Programm defensiv es (das heißt sanieren sie) es wäre falsch, eine Ausnahme für ungültige Eingaben zu werfen -. Erwartet wird,

Für Code, der gemeint ist, mit bereits desinfiziert und validiert Eingang befassen, die mit dem Benutzer ihren Ursprung haben, werfen eine Ausnahme bestehen würden, wenn Sie etwas Eingang gefunden, die verboten werden soll. Die Telefonvorwahl ist, den Vertrag in diesem Fall zu verletzen, und es gibt einen Fehler in der Hygienisierung und / oder Telefonvorwahl.

Wartbarkeit - Ausnahmen erstellen ungeradee Codepfade, nicht unähnlich GOTOs.
Einfache Bedienung (für andere Klassen) - Andere Klassen können darauf vertrauen, dass Ausnahmen von Ihrem Benutzer angehoben Eingangsklasse sind tatsächliche Fehler
Performance - In den meisten Sprachen ein Ausnahme verursacht eine Leistung und Speichernutzung Strafe.
Beschreibung - Die Bedeutung der Worte does matter. Bad-Eingang ist nicht "Außergewöhnlich".

Wenn Ausnahmen verwenden, die Fehlerbehandlung Code aus dem Code getrennt den Fehler verursacht . Das ist die Absicht der Ausnahmebehandlung - Ausnahmezustand befindet, kann der Fehler nicht vor Ort behandelt werden, so wird eine Ausnahme zu einem höheren (und unbekannten) Umfang geworfen. Wenn nicht behandelt, wird die Anwendung, bevor verlassen mehr hart gemacht wird.

Wenn Sie immer, immer, immer Ausnahme auslösen, wenn Sie einfache logische Operationen durchführen, wie Benutzereingaben zu überprüfen, können Sie etwas tun, sehr, sehr, sehr falsch.

Der Eingang ist nicht, was erwartet wurde, und daher ist außergewöhnlich.

Diese Aussage sitzt nicht gut mit mir überhaupt nicht. Entweder ist die UI schränkt Benutzereingabe (zB die Verwendung eines Schiebers, der Min- / Max-Werte begrenzt), und Sie können jetzt bestimmte Bedingungen behaupten - keine Fehlerbehandlung erforderlich. Oder kann der Benutzer Müll eingeben und Sie erwarten, dass dies geschehen kann und muss damit umgehen. Der eine oder andere -. Es gibt nichts Ausnahme hier überhaupt geht

eine Ausnahme Werfen erlaubt mir, genau definieren, was falsch war wie StringValueTooLong oder oder IntegerValueTooLow oder InvalidDateValue oder Wasauchimmer. Warum wird dies als falsch?

Ich halte diese darüber hinaus - näher an das Böse. Sie können eine abstrakte Schnittstelle Errorprovider definieren oder ein komplexes Objekt zurückgeben den Fehler eher als eine einfache Code repräsentiert. Es gibt viele, viele Möglichkeiten, wie Sie Fehlermeldungen abzurufen. Mit Ausnahmen, weil die sind praktisch ist so, so falsch . Ich fühle mich schmutzig nur diesen Absatz zu schreiben.

Denken Sie an eine Ausnahme als die Hoffnung zu werfen. Eine letzte Chance. Ein Gebet. Validieren von Benutzereingaben nicht auf eine dieser Bedingungen führen.

Ist es möglich, dass einige der Meinungsverschiedenheit zu einem Mangel an Konsens beruht, was ‚Benutzereingabe‘ bedeutet? Und in der Tat, auf welcher Ebene Sie Codierung.

Wenn Sie eine GUI-Benutzeroberfläche sind Codierung oder einen Web-Formular-Handler, könnten Sie auch ungültige Eingabe erwarten, da es von der Typisierung Finger eines Menschen direkt gekommen ist.

Wenn Sie das Modell Teil einer MVC-app sind Codierung, können Sie entwickelt haben sich die Dinge so, dass der Controller-Eingänge für Sie hygienisiert hat. Ungültige Eingabe bis zum Modell bekommen würde in der Tat eine Ausnahme sein und als solche behandelt wird.

Wenn Sie einen Server auf Protokollebene sind Codierung, könnte man vernünftigerweise erwarten, dass der Client-Benutzereingabe zu überprüfen. Auch hier ungültige Eingabe wäre in der Tat eine Ausnahme sein. Das ist ganz verschieden von dem Client 100% zu vertrauen (das wäre in der Tat sehr dumm sein) - aber im Gegensatz zum direkten Benutzereingabe vorhersagen, dass die meisten der Zeiteingaben in Ordnung sein würden. Die Linien verschwimmen hier etwas. Desto wahrscheinlicher ist es, dass etwas geschieht, desto weniger wollen Ausnahmen verwenden, um es zu behandeln.

Dies ist eine sprachliche pov (Sicht) über die Angelegenheit.

Warum sind Ausnahmen der so schlecht für die Gültigkeitsprüfung sein?

Schlussfolgerung:

Ausnahmen sind nicht klar genug definiert, so gibt es verschiedene Meinungen.
Falsche Eingabe wird als normale Sache gesehen, nicht als Ausnahme.

Gedanken?

Es kommt wahrscheinlich bis zu den Erwartungen, die man über den Code nimmt die erstellt wird.

der Client kann nicht vertraut werden
- Validierung hat auf dem Server-Seite passieren. stärker. alle Validierung geschieht Seite bei Server
- , da die Validierung an der Seite des Servers geschieht es ist erwartet es getan werden und was erwartet wird, ist keine Ausnahme, da es erwartet wird.

Allerdings

des Clients Eingabe kann man nicht trauen
des Clients Eingabevalidierung können trauen
- , wenn die Validierung vertraut ist, kann es sein, erwartet erzeugen gültige Eingabe
- jetzt wird jeder Eingang erwartet gültig sein
- ungültige Eingabe ist nun unerwartet, eine Ausnahme

Ausnahmen können eine nette Art und Weise sein, den Code zu verlassen.

Eine Sache zu prüfen, erwähnt ist, wenn Ihr Code in ordnungsgemäßem Zustand verlassen wird. Ich weiß nicht, was meinen Code in einem ungeeigneten Zustand verlassen. Verbindungen erhalten automatisch geschlossen, übrig gebliebene Variablen sind Garbage Collection, was ist das Problem?

Eine weitere Stimme gegen die Ausnahmebehandlung für Dinge, die nicht Ausnahmen sind!

In .NET die JIT-Compiler-Optimierungen in bestimmten Fällen nicht einmal ausführen, wenn Ausnahmen nicht geworfen werden. Die folgenden Artikel erklären es gut. http: // msmvps.com/blogs/peterritchie/archive/2007/06/22/performance-implications-of-try-catch-finally.aspx http://msmvps.com/blogs/peterritchie/archive/2007/07/12/performance-implications-of-try-catch-finally-part-two.aspx
Wenn eine Ausnahme geworfen wird es eine ganze Reihe von Informationen für die Stack-Trace erzeugt, die erforderlich sein können, nicht, wenn Sie tatsächlich wurden die Ausnahme „erwarten“, wie es oft der Fall, wenn Strings Umwandlung in int des etc ...

In der Regel werfen Bibliotheken Ausnahmen und Kunden fangen sie und tun etwas intelligenter mit ihnen. Für Benutzereingaben schreibe ich Funktionen Validierung nur statt Ausnahmen zu werfen. Ausnahmen scheinen übertrieben für so etwas.

Es gibt Probleme mit der Leistung Ausnahmen, aber in GUI-Code finden Sie im Allgemeinen nicht über sie kümmern. Was also, wenn eine Validierung nimmt ein zusätzlichen 100 ms zu laufen? Der Benutzer wird nicht bemerken, dass.

In gewisser Weise ist es eine schwierige - Auf der einen Seite, die Sie nicht Ihre gesamte Anwendung haben wollen zusammenbrechen, weil der Benutzer eine zusätzliche Ziffer in einer Postleitzahl Textfeld eingegeben und Sie vergessen, die Ausnahme zu behandeln. Auf der anderen Seite ein ‚früh scheitern, scheitern harten‘ Ansatz stellt sicher, dass Fehler schnell zu bekommen entdeckt und behoben und hält Ihre wertvollen Datenbank gesund. Generell denke ich, die meisten Frameworks empfehlen, dass Sie Ausnahme nicht für UI-Fehlerprüfung und einige, wie .NET Windows Forms verwenden Handhabung, schöne Möglichkeiten bieten diese (ErrorProviders und Validierung Ereignisse) zu tun, ohne Ausnahmen.

Ausnahmen sollten nicht für Eingabeüberprüfung verwendet werden, da nicht nur Ausnahmen in Ausnahmefällen verwendet werden sollen (was, wie es falsch Benutzereintrag ist nicht darauf hingewiesen wurde), aber sie schaffen außergewöhnliche Code (nicht im brillanten Sinne).

Das Problem mit Ausnahmen in den meisten Sprachen ist sie die Regeln des Programmablaufes ändern, ist dies in einem wirklich außergewöhnlichen Umstand in Ordnung, wo es nicht unbedingt möglich ist, unser Figur, was der gültige Fluss sollte und daher nur eine Ausnahme auslösen und erhält sich jedoch heraus, wo Sie wissen, was die Strömung sollte man diesen Fluss schaffen sollte (im Fall aufgeführt, es würde eine Nachricht an den Benutzer zu erhöhen, werden ihnen zu sagen, sie müssen einige Informationen neu eingeben).

Ausnahmen waren wirklich überstrapazieren in einer Anwendung, die ich täglich arbeiten und auch für den Fall, dass ein Benutzer ein falsches Kennwort eingegeben bei der Anmeldung, die durch Ihre Logik eine Ausnahme Ergebnis sein würde, weil es nicht das, was die Anwendung will. Jedoch, wenn ein Prozess ein von zwei Ergebnissen hat entweder richtig oder falsch, ich glaube nicht, können wir sagen, dass, falsch, egal wie falsch, außergewöhnlich ist.

Eines der wichtigsten Probleme, die ich mit der Arbeit mit diesem Code gefunden habe versucht, die Logik des Codes zu folgen, ohne mit dem Debugger tief einzulassen. Obwohl Debugger groß sind, sollte es möglich sein, Logik hinzufügen, was passiert, wenn ein Benutzer ein falsches Kennwort eingibt, ohne eine bis feuern zu müssen.

Halten Sie Ausnahmen für wirklich außergewöhnliche Ausführung nicht einfach falsch. Im Fall war ich hervorheben Ihr Passwort falsch bekommen nicht außergewöhnlich, aber nicht kann sein, in der Lage, der Domain-Server zu kontaktieren!

Wenn ich sehe, Ausnahmen für die Validierung Fehler geworfen ich oft sehen, dass die Methode, um die Ausnahme zu werfen ist eine Menge Validierungen auf einmal durchführen. z.

public bool isValidDate(string date)
{
    bool retVal = true;
    //check for 4 digit year
    throw new FourDigitYearRequiredException();
    retVal = false;

    //check for leap years
    throw new NoFeb29InANonLeapYearException();
    retVal = false;
    return retVal;
}

Dieser Code neigt dazu, ziemlich zerbrechlich und schwer zu pflegen zu sein, da die Regeln im Laufe der Monate und Jahre anhäufen. Ich ziehe es in der Regel meine Validierungen in kleinere Methoden zu brechen, die bools zurückzukehren. Es macht es einfacher, die Regeln zu optimieren.

public bool isValidDate(string date)
{
    bool retVal = false;
    retVal = doesDateContainAFourDigitYear(date);
    retVal = isDateInALeapYear(date);
    return retVal;
}

public bool isDateInALeapYear(string date){}

public bool doesDateContainAFourDigitYear(string date){}

Wie bereits erwähnt wurde, zurückkehr einen Fehler struct / Objekt enthält Informationen über den Fehler ist eine großartige Idee. Der offensichtlichste Vorteil ist, dass man sie auf und zeigt alle Fehlermeldungen an den Benutzer auf einmal anstatt sie sammeln kann Whack-A-Mole mit der Validierung spielen.

i verwendet eine Kombination aus beidem eine Lösung: für jede Validierungsfunktion, übergeben i eine Aufzeichnung, die ich mit den Validierungsstatus (ein Fehlercode) zu füllen. am Ende der Funktion, wenn ein Validierungsfehler vorhanden ist, werfe ich eine Ausnahme, auf diese Weise i, keine Ausnahme für jedes Feld werfen aber nur einmal. Ich habe auch den Vorteil, dass eine Ausnahme zu werfen Ausführung stoppen, weil ich auch weiterhin nicht die Ausführung will, wenn Daten ungültig ist.

zum Beispiel

procedure Validate(var R:TValidationRecord);
begin
  if Field1 is not valid then
  begin
    R.Field1ErrorCode=SomeErrorCode;
    ErrorFlag := True; 
  end; 
  if Field2 is not valid then
  begin
    R.Field2ErrorCode=SomeErrorCode;
    ErrorFlag := True; 
  end;
  if Field3 is not valid then
  begin
    R.Field3ErrorCode=SomeErrorCode;
    ErrorFlag := True; 
  end;

  if ErrorFlag then
    ThrowException
end;

, wenn nur auf boolean angewiesen, die Entwickler meine Funktion dieser Rechnung schriftlich erfolgen sollte:

if not Validate() then
  DoNotContinue();

aber er kann vergessen und nur nennen Validate () (ich weiß, dass er nicht sollte, aber vielleicht könnte er).

so, in dem obigen Code i die zwei Vorteile erzielt: 1-nur eine Ausnahme in der Validierungsfunktion. 2-Ausnahme, auch nicht abgefangene, wird die Ausführung stoppen und zur Testzeit angezeigt werden.

8 Jahre später, und ich laufe in das gleiche Dilemma versucht, das CQS Muster anzuwenden. Ich bin auf der Seite, dass die Eingabevalidierung eine Ausnahme auslösen kann, aber mit einer zusätzlichen Einschränkung. Falls eine Eingabe fehlschlägt, müssen Sie eine Art von Ausnahme werfen: Validation, BrokenRuleException usw. nicht eine Reihe von verschiedenen Arten Werfen Sie da es unmöglich sein wird, sie alle zu behandeln. Auf diese Weise erhalten Sie eine Liste aller gebrochenen Regeln an einem Ort. Sie erstellen eine einzige Klasse, die dafür Validierung (SRP) und werfen eine Ausnahme, wenn mindestens 1-Regel gebrochen ist verantwortlich ist. Auf diese Weise umgehen Sie eine Situation mit einem Haken und Sie wissen, dass Sie gut sind. Sie können dieses Szenario behandeln, egal, welcher Code genannt wird. Dies lässt den gesamten Code Downstream viel sauberer, wie Sie wissen, dass es in einem gültigen Zustand ist oder es würde nicht bekommen haben.

Für mich von einem Benutzer ungültige Daten bekommen ist nicht etwas, das man normalerweise erwarten würde. (Wenn jeder Benutzer zu Ihnen das erste Mal ungültige Daten sendet, würde ich einen zweiten Blick auf der Benutzeroberfläche nehmen.) Alle Daten, die Sie bei der Verarbeitung der wahre Absicht verhindert ob es Benutzer oder als Quelle muss an anderer Stelle Verarbeitung abzubrechen. Wie kommt es, anders als ein Argument aus einem einzigen Stück Daten zu werfen, wenn es eine Benutzereingabe ist gegen sie ein Feld auf einer Klasse zu sein, der sagt dies erforderlich ist.

Natürlich könnten Sie Validierung zuerst tun und schreiben, dass die gleichen Standardcode auf jedem einzelnen „Befehl“, aber ich denke, das ist ein Alptraum in Sachen Wartung als Fang ungültige Benutzereingaben an einem Ort an der Spitze, die die gleiche Art und Weise behandelt werden, unabhängig . (Less-Code!) Der Performance-Hit wird nur kommen, wenn der Benutzer ungültige Daten gibt, die nicht so oft passieren sollte (oder Sie haben schlechte UI). Jede und alle Regeln auf der Client-Seite sind auf dem Server neu geschrieben werden, wie auch immer, so könnte man sie nur einmal schreiben, tun einen AJAX-Aufruf, und die <500 ms Verzögerung spart Ihnen eine Menge Zeit-Codierung (nur 1 Platz, um alle Ihre Validierungslogik zu setzen).

Auch wenn Sie einige nette Validierung mit ASP.NET aus der Box tun, wenn Sie Ihre Validierungslogik in anderen UIs wiederverwenden möchten, können Sie nicht, da es in ASP.NET gebacken. Sie wären besser dran, etwas weiter unten zu schaffen und es oben unabhängig von den UI Handhabung verwendet wird. (My 2 cents, zumindest.)

ich mit Mitch darüber einig, dass die „Ausnahmen sollten nicht für die normalen Kontrollfluss verwendet werden“. Ich möchte nur hinzufügen, dass von dem, was ich von meinen Informatik-Klassen erinnere, Ausnahmen zu kontrollieren teuer ist. Ich habe nie wirklich versucht, Benchmarks zu tun, aber es wäre interessant Leistung zwischen etwa zu vergleichen, einem if / else vs try / catch.

Ein Problem Ausnahme bei der Verwendung eine Tendenz, nur ein Problem auf einmal zu erfassen. Der Benutzer legt das und erneut sendet, nur ein weiteres Problem zu finden! Eine Schnittstelle, die eine Liste von Fragen zurückgibt, ist viel freundlicher braucht Lösung (obwohl es in Ausnahmefällen eingewickelt werden könnte).

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow