Sollte eine Geschäftsregelverletzung eine Ausnahme auslösen?

Question

Sollte eine Verletzung einer Geschäftsregel eine Ausnahme auslösen?

Answer 1

Nein. Es ist Teil der normalen Logik für die bedingte Verarbeitung im Programm (und oft nur eine verschleierte Form von Benutzerfehler).

Answer 2

Es hängt davon ab, was die Geschäftsregel ist, IMO. Ich würde es wagen, "nicht normalerweise" zu sagen, aber ich würde es von Fall zu Fall betrachten. Ich glaube nicht, dass es eine einzige Antwort gibt, da verschiedene Geschäftsregeln dies rechtfertigen könnten, während andere dies möglicherweise nicht tun.

Answer 3

Wegen der Art, wie ich meine Validierung und meine Verwendung von LINQtoSQL für ORM, ja. Wenn eine Entität die Validierung einer Geschäftsregel während der OnValidate-Methode nicht besteht, besteht die einzige Möglichkeit, den aufrufenden Code zu benachrichtigen, darin, eine Ausnahme auszulösen. In diesem Fall erstelle ich eine benutzerdefinierte DataValidationException. Die Verwendung der OnValidate-Methode in einer partiellen Klassenimplementierung der Entität ermöglicht es mir, die Validierung für update/insert zu erzwingen, sodass nur gültige Daten in der Datenbank gespeichert werden.

BEARBEITEN Ich sollte klarstellen, dass ich in der Regel Validierung der Benutzereingaben auf dem Client, so dass die Persistenzschicht Validierung ist in der Regel mehr Versicherung und selten, wenn überhaupt, scheitert. Ich behandle die clientseitige Validierung nicht als Ausnahmen, sondern mit bedingter Logik.

Answer 4

Meinst du zum Beispiel, dass ein Wert im Bereich von 0 bis 99 liegen soll, aber irgendwie endete 105?

Wenn es vom Benutzer kommt, ist es eine Frage der Validierung. Ob Sie Ausnahmen verwenden oder nicht, hängt von den Idiomen Ihrer Sprache ab.

Wenn es von Ihrem Datenspeicher kommt, dann ja, es scheint vernünftig, eine Ausnahme zu werfen. Es bedeutet, dass Sie schlechte Daten haben, und Sie müssen herausfinden, wie es dort angekommen ist und verhindern, dass es wieder passiert.

Answer 5

Das Werfen von Ausnahmen kann rechenintensiv sein, sie liegen außerhalb der Norm. Zum Beispiel in .net haben Sie Leistungsindikatoren, die inkrementiert werden - das ist ein Schwergewicht activivty und so nicht etwas, das Sie statt einer einfachen Bedingung tun möchten.

Answer 6

Es hängt wirklich davon ab, was es ist und wo es ist.

Wenn es einige Daten vom Benutzer gibt, dann als levand sagte, es ist eine Frage der Validierung. Die Validierung kann sowohl erfolgreich als auch fehlgeschlagen sein. Beide Optionen werden mit klaren weiteren Aktionsszenarien erwartet.

Wenn es etwas wie Methodenausführungsfehler ist, könnte es eine bessere Idee sein, eine Ausnahme zu werfen und dort anzuhalten, bevor mehr Schaden angerichtet wird (z. B. das Erzeugen von Inkonsistenzen in der Datenbank).

Es ist oft eine Frage der Perspektive und Ihres Anwendungsdesigns.

Answer 7

Usualy habe ich den Zustand in einer Spezifikation Objekt, das

bool IsVerfiedBy(T entity); 

So setzt man den Zustand ohne Ausnahme überprüfen.

Wenn in Ihrem Code eine Stelle vorhanden ist, an der die Spezifikation zuvor verifiziert werden soll, können Sie eine Ausnahme auslösen, da dies eine Voraussetzung für Ihre Funktion ist.

Wenn Ihre Entität beispielsweise vor der Persistenz in einem bestimmten Zustand sein muss, eine Ausnahme auslösen, wenn die Spezifikation nicht verifiziert ist, aber die Spezifikation vor dem Persistieren verwenden, damit die Ausnahme nicht auftritt.

Answer 8

würde ich normalerweise nicht sagen, aber ich glaube nicht, dass Sie niemals sagen können.

Zum Beispiel hängt es davon ab, wer/was die fehlgeschlagene Regel behandelt. Wenn es eine Benutzerschnittstelle/Benutzer ist, würde ich bedingte Logik verwenden, um den Fehler angemessen zu behandeln. Wenn es sich jedoch um einen Geschäftsregelfehler handelt, beispielsweise bei einem gesichtslosen Prozess, bei dem Fehler in einem Ereignisprotokoll protokolliert werden, das von einer technischen Ressource überwacht wird, kann eine Ausnahme genauso sinnvoll sein. In diesem späteren Fall kann eine entsprechend benannte Ausnahme genauso hilfreich sein wie eine schön formatierte Nachricht.

Answer 9

Als Alternative im Hinblick auf den meisten Antworten ...

Es kann nützlich sein, Ausnahmen von der Geschäftslogik zu werfen, vor allem, wenn sie durch einen Fehler bei der Validierung cuased werden. Wenn Sie ein Objekt erwarten und eine Null erhalten, deutet dies darauf hin, dass ein Problem in der Benutzeroberfläche (oder einer anderen Schnittstelle) erkannt wurde. Es kann durchaus gelten, dass an dieser Stelle Ausnahmen ausgelöst werden. In der Tat können Sie diese Art der Validierung in der Geschäftslogik platzieren, wenn mehrere Schnittstellen vorhanden sind.

Ausnahmen in einigen Sprachen/Frameworks zu werfen (ich denke .NET) kann teuer sein, aber das sollte Sie nicht sofort beunruhigen. Es bedeutet, dass sie, wie der Name schon sagt, für außergewöhnliche Umstände und nicht als Teil des Standardablaufs eines Programms verwendet werden. Sie sollten sicherlich keine Ausnahme auslösen, nur um eine Methode zu beenden. Sie sollten auch eine möglichst schöne Wiederherstellung in Erwägung ziehen, die möglicherweise keine Ausnahme enthält.

Also, zusammenfassend ... Es hängt davon ab ...

Answer 10

Zuerst ein paar Zitate aus Kapitel 18 von Applied Microsoft .NET Framework-Programmierung (Seite 402) von Jeffrey Richter:

" Ein weiteres häufiges Missverständnis ist, dass eine "Ausnahme" einen "Fehler" identifiziert. "

"Eine Ausnahme ist die Verletzung der impliziten Annahmen einer programmatischen Schnittstelle."

Wenn ich richtig aus Ihrer Frage Folgern, dass ein Geschäftsregelverletzung Daten sein würde, die außerhalb eines bestimmten Bereichs fällt (zum Beispiel), das ist ein Fehler, den Sie mit einem bedingten umgehen können als „ahockley“ vorgeschlagen . Basierend auf der Definition einer Ausnahme von Richter wäre die angemessene Verwendung einer Ausnahme dann sinnvoll, wenn Ihr Code keine Geschäftsregel aus dem von Ihnen verwendeten Repository abrufen konnte. Die Möglichkeit, eine Geschäftsregel abzurufen, wäre eine vernünftige implizite Annahme für diese Schnittstelle, sodass eine Ausnahme ausgelöst werden sollte, wenn diese Annahme verletzt wird.

Ein gutes Beispiel für Richters erstes Zitat (Ausnahme! = Fehler) ist die ThreadAbortException. Wenn Sie Response.Redirect (URL) (in ASP.NET) aufrufen, wird eine ThreadAbortException ausgelöst, obwohl die Weiterleitung erfolgreich ist. Warum? Die implizite Annahme der Ausführung von ASP.NET-Seiten ist, dass eine Seite vollständig ausgeführt wird. Response.Redirect (URL) verletzt diese Annahme, daher die Ausnahme.

Answer 11

Geschäftsregeln sollten keine Ausnahme auslösen, es sei denn, sie werden zur Validierung von Parametern einer API (z. B .: Gültigkeitsprüfung von Anforderungen) oder in Komponententests (z. B. using business rules to simplify .NET unit tests) verwendet.

Im Allgemeinen geben Geschäftsregeln jedoch Fehler- und Warnmeldungen an den Gültigkeitsbereich aus.

Answer 12

Nein Die Verletzung einer Geschäftsregel ist ein BUSINESS-Problem, bei dem es sich um eine technische Ausnahme handelt. Die Verletzung einer Geschäftsregel ist etwas, das das System als normal betrachten sollte und für das es eine programmierte Antwort, nicht eine Ausnahme, haben sollte.

Answer 13

Geschäftsregeln können eine Ausnahme auslösen, sollten dies aber nicht tun.

Wenn Sie eine andere Möglichkeit haben, Informationen über häufige und vorhersehbare Validierungsfehler zu übermitteln, sollten Sie sie verwenden.

Answer 14

Es ist eine gute Führung in der wiki for the book97 Dinge, die jeder Projektmanager Sollte wissen, insbesondere im Kapitel Distinguish Business Exceptions from Technical.

Also, wenn Ihre Programmiersprache es unterstützt, ist das Beste, benutzerdefinierte Ausnahmeklassen zu erstellen, so dass deren Workflow und Handhabung von technischen Ausnahmen abweichen können.