Die Verwendung der Ausnahmeklasse in c #

https://stackoverflow.com/questions/109790

02-07-2019
|

Frage

Fehler, die in einer Datenzugriffsschicht oder sogar höher, (sagen wir innerhalb ADO.net Operationen zum Beispiel) auftreten tief unten selten viel Sinn für einen Endbenutzer machen. Einfach diese Fehler sprudeln zu einer UI und deren Anzeige in der Regel nichts außer Frustration für einen Endbenutzer erreichen wird.

ich eine grundlegende Technik vor kurzem verwendet haben für Fehler wie diese Berichterstattung wobei ich den Fehler abzufangen und zumindest einige benutzerfreundliche Text hinzufügen, so dass zumindest der Endverbraucher versteht, was fehlgeschlagen ist.

Um dies zu tun, ich eine Ausnahme in jeder spezifischen Funktion am Fang (sagen sie für ein Beispiel Abruffunktion in einer Datenzugriffsschicht), dann mit benutzerfreundlichen Text über die Funktion einen neuen Fehler verursacht, die versagt hat und wahrscheinlich dazu führen, aber dann die ursprüngliche Ausnahme in der neuen Ausnahme als die „innere Ausnahme“ dieser neue Ausnahme einzubetten.

Dies kann dann bei jeder Schicht auftreten, wenn nötig, jeden Verbraucher der unteren Funktionsebene eines eigenen Kontext zu der Fehlermeldung hinzugefügt, so dass das, was erreicht der UI ist eine zunehmend benutzerfreundliche Fehlermeldung.

Sobald erreicht der Fehler der Benutzeroberfläche - falls notwendig - es kann dann durch die verschachtelten Ausnahmen um iterieren eine Fehlermeldung angezeigt werden, die zum einen dem Benutzer mitteilt, die den Betrieb ausgefallen ist, sondern auch ein wenig von technischen Informationen über das, was schief ging tatsächlich .

"Die Liste der Kundennamen Ihrer   angeforderte konnte nicht angezeigt werden. "

"Abrufen der Liste der Kunden   Sie aufgefordert, auf einen Fehler mit der Datenbank, scheitern. "

"Es gab einen Fehler zu den Verbindungs   Datenbank beim Abrufen einer Liste von   Kunden "

"Fehler bei der Anmeldung für den Benutzer xx"

Meine Frage lautet: Ist das schrecklich ineffizient (alle diese verschachtelten Ausnahmen)? Ich vermute, es ist nicht die beste Praxis so etwas soll mir das Gleiche zu erreichen tun - oder soll ich in der Tat versuchen, etwas besser zu erreichen

Lösung

Es ist nur etwas schrecklich.

Wenn Sie einen Fehler an den Endbenutzer angezeigt werden, wird der Benutzer soll in der Lage sein, über sie zu handeln. In „Die Liste von Kundennamen Ihres Wunsch konnte nicht angezeigt werden.“ Fall Ihre Benutzer wird denken, nur „so was?“ In all diesen Fällen zeigen nur eine Meldung „etwas Schlimmes passiert ist“. Sie brauchen nicht einmal, diese Ausnahmen zu fangen, wenn etwas schlecht geht, lassen Sie einige globale Methode (wie Application_Error) damit umgehen und eine allgemeine Meldung angezeigt werden soll. Wenn Sie oder Ihre Benutzer etwas über den Fehler tun, es fangen und die Sache zu tun oder den Benutzer benachrichtigen.

Aber Sie werden alle Fehler protokollieren wollen, dass Sie nicht behandeln.

Durch die Art und Weise, die Anzeige von Informationen über die Fehler auftreten können Sicherheitslücken ergeben. Je weniger die Angreifer wissen über Ihr System, desto weniger wahrscheinlich werden sie Wege finden, es zu hacken (denken Sie daran, diese Nachrichten wie „Syntaxfehler in der SQL-Anweisung: SELECT * FROM Benutzer Wo username =‚a‘; DRP-Datenbank; -‘ .. .“zu erwarten:..‚drop‘anstelle von‚DRP‘Sie wie diese machen Websites nicht mehr)

Andere Tipps

Es ist technisch aufwendig neue Ausnahmen zu werfen, aber ich werde keine große Debatte aus, dass da „teuer“ machen ist relativ - wenn Sie werfen 100 solche Ausnahmen eine Minute, werden Sie wahrscheinlich die Kosten nicht sehen; wenn Sie werfen 1000 solche Ausnahmen eine zweite, können Sie sehr gut eine Performance-Einbußen sehen (also nicht wirklich der Rede wert hier - Leistung ist Ihr Anruf).

Ich glaube, ich habe zu fragen, warum dieser Ansatz verwendet wird. Ist es wirklich wahr, dass Sie auf sinnvolle Ausnahmeinformationen hinzufügen können alle Ebene, wo eine Ausnahme könnte geworfen werden, und wenn ja, ist es auch wahr, dass die Informationen sein:

Etwas, das Sie eigentlich will mit Ihrem Benutzer teilen?
Something Ihre Benutzer zu interpretieren Lage sein, zu verstehen und verwenden
Geschrieben in einer solchen Art und Weise, dass sie mit späteren Wiederverwendung von Low-Level-Komponenten nicht stört, kann der Nutzen von denen nicht bekannt ist, wenn sie geschrieben wurden?

Ich bitte um Informationen mit Ihrem Benutzer teilen, weil in Ihrem Beispiel Ihre künstlichen Stapel beginnen, indem den Benutzer darüber informiert, ein Problem der Authentifizierung auf der Datenbank dort war. Für einen möglichen Hacker, das ist ein gutes Stück von Informationen, die etwas über das, was die Operation macht tat.

Wie für das Austeilen eines ganzen benutzerdefinierten Ausnahme-Stack zurück, ich glaube nicht, es ist etwas, das den meisten (ehrlich) Anwender von Nutzen sein wird. Wenn ich Probleme habe eine Liste von Kundennamen bekommen, zum Beispiel, wird es mir helfen (als Benutzer) zu wissen, dass es ein Problem mit der Datenbank authentifiziert war? Es sei denn, Sie verwenden integrierte Authentifizierung und jeder Benutzer hat ein Konto, und die Fähigkeit, ein Systemadministrator zu wenden, um herauszufinden, warum ihr Konto Privilegien fehlt, wahrscheinlich nicht.

Ich würde beginnen, indem zunächst entscheiden, ob es wirklich ein semantischer Unterschied zwischen der Rahmen Ausnahme ausgelöst und der Ausnahmemeldung SieFormal den Benutzer zur Verfügung zu stellen mögen. Wenn ja, dann gehen Sie vor und eine benutzerdefinierte Ausnahme auf der untersten Ebene verwenden ( ‚Anmeldung fehlgeschlagen‘ in Ihrem Beispiel). Die Schritte, die bis zur eigentlichen Präsentation der Ausnahme, nicht wirklich alle benutzerdefinierten Ausnahmen erfordern. Die Ausnahme, die Sie interessiert sind bereits erzeugt worden ist (die Anmeldung ist fehlgeschlagen) - weiterhin auf allen Ebenen des Call-Stack diese Nachricht wickeln dient keinen wirklichen Zweck anders als Ihre Call-Stack an die Benutzer ausgesetzt wird. Für die „mittlere“ Schritte, vorausgesetzt, alle try / catch-Blöcke sind vorhanden, ein einfaches ‚log und werfen‘ Strategie würde gut funktionieren.

Wirklich, obwohl, hat diese Strategie eine andere mögliche Fehler: es zwingt, auf dem Entwickler die Verantwortung, die benutzerdefinierte Ausnahme Standard für die Pflege, die implementiert worden ist. Da Sie möglicherweise nicht jede Permutation der Aufrufhierarchie kennen kann, wenn Low-Level-Typen zu schreiben (ihre „Kunden“ könnte noch nicht einmal geschrieben worden sind), scheint es unwahrscheinlich, dass alle Entwickler - oder sogar ein Entwickler - würde sich erinnern wickeln und anpassen jede Fehlerbedingung in jedem Codeblock.

Statt vom Boden Aufarbeiten Ich mache mir Sorgen typischerweise etwa die Anzeige von geworfen Ausnahmen so spät in den Prozess wie möglich (das heißt möglichst nahe an der „Spitze“ des Call-Stack wie möglich). Normalerweise Ich versuche nicht, alle Nachrichten in Ausnahmen auf einem niedrigen Niveau meiner Anwendungen geworfen zu ersetzen - vor allem, da die Nutzung dieser geringen Mitglieder neigen dazu, der Anruf wird immer abstrakter desto tiefer zu bekommen. Ich neige dazu, Ausnahmen in dem Business-Tiere zu fangen und zu protokollieren und niedriger, dann behandeln sie in nachvollziehbarer Weise in der Präsentationsebene angezeigt wird.

Hier sind ein paar anständige Artikel auf Ausnahmebehandlung Best Practices:

http://www.codeproject.com/KB/architecture/exceptionbestpractices.aspx

http://aspalliance.com/1119

Herrje diese bekamen wortreich ... Entschuldigungen im Voraus.

Ja, Ausnahmen sind teuer, so dass es eine Kosten in Fang- und Erneutes Auslösen oder werfen eine nützlichere Ausnahme beteiligt ist.

Aber warten Sie eine Minute! Wenn der Framework-Code oder die Bibliothek, die Sie verwenden, um eine Ausnahme wirft dann die Dinge kommen schon unstuck. Haben Sie nicht-funktionale Anforderungen an, wie schnell eine Fehlermeldung nach einer Ausnahme propagiert wird? Das bezweifle ich. Ist es wirklich eine große Sache? Etwas Unvorhergesehenes und ‚außergewöhnlich‘ geschehen ist. Die Hauptsache ist sinnvoll, hilfreiche Informationen für den Benutzer zu präsentieren.

Ich glaube, Sie auf dem richtigen Weg sind mit dem, was Sie tun.

Natürlich ist es schrecklich ineffizient. Aber an dem Punkt, dass eine Ausnahme auftritt, dass wichtig genug ist, um die Endbenutzer zu zeigen, sollte man darüber nicht.

Wo ich arbeite, haben wir nur ein paar Gründe Ausnahmen zu fangen. Wir tun es nur, wenn ...

Wir haben etwas dagegen tun können - z. B. Wir wissen, dass dies manchmal passieren kann, und wir können es in Code korrigieren, wie es geschieht (sehr selten)
Wir wollen wissen, es passiert und wo (dann haben wir nur die Ausnahme erneut auslösen).
Wir wollen eine freundliche Nachricht hinzuzufügen, in dem Fall, dass wir die ursprüngliche Ausnahme in neuer excpetion wickeln abgeleitet von Anwendungsausnahme und fügen Sie eine freundliche Nachricht an das und es dann von diesem Punkt sprudelt unverändert lassen.

In Ihrem Beispiel würden wir wahrscheinlich angezeigt werden nur „Logon Fehler aufgetreten ist.“ ANBD es dabei belassen, dass, während die reale Fehlerprotokollierung und eine Bereitstellung warum für den Benutzer in die Ausnahme bohren, wenn sie zu wollen. (Vielleicht eine Taste auf der Fehlerform).

Wir wollen die Ausnahme vollständig zu unterdrücken und weiterzumachen. Es erübrigt sich zu sagen, dass wir dies nur tun, für die erwarteten Ausnahmetypen und nur dann, wenn es keine andere Möglichkeit ist, den Zustand zu erkennen, der die Ausnahme erzeugt.

Im Allgemeinen, wenn Sie mit Ausnahmen zu tun hat, Leistung und Effizienz ist die wenigsten Sorgen. Sie sollten mehr besorgt sein, etwas zu tun der Benutzer erholen sich von dem Problem zu helfen. Wenn es ein Problem war, eine bestimmte Datensatz in die Datenbank zu schreiben, entweder die Änderungen rückgängig zu machen oder zumindest die Zeileninformationen Dump so dass der Benutzer es nicht verlieren wird.

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow