Transparente generische Ausnahmebehandlung für asp.net / MOSS2007 (mit Code) [geschlossen]

Nicht gerade eine Frage, aber etwas, das einigen Leuten helfen könnte, hoffe ich.

Vor einiger Zeit habe ich ein allgemeines, transparentes Ausnahmebehandlungsmodul zur Verwendung in einer MOSS 2007 (Sharepoint) -Lösung geschrieben. Die Lösung hatte viele Webparts, Webparts, die oft kaputt gingen und die gesamte Seite zum Absturz brachten. Dies führte dazu, dass unsere Tester kein Ende des Elends sahen, da sie nicht so leicht erkennen konnten, welcher Teil der Seite für den Absturz verantwortlich war, noch konnten sie ihre Tests fortsetzen, bis der Web-Teil repariert worden war. Oft war der abstürzende Webpart für die Tester nicht einmal relevant, aber er hielt sie davon ab, ihre Arbeit zu erledigen. Offensichtlich musste etwas getan werden.

Sie könnten argumentieren, dass die beste Lösung wäre, sich anzulegen und nur die Dang-Web-Teile zu reparieren. Aber es gab eine Menge von ihnen, und die für das Chaos verantwortlichen Programmierer waren weitergezogen (klingt vertraut?), also hatten wir die Idee, eine allgemeine Allzweck-Ausnahmebehandlungsstrategie für die Teile zu verwenden.

Wir wollten einen Absturz in einem Webpart oder Web-Control usw., um die gesamte Seite nicht abzustürzen, sondern den Stacktrace während der Entwicklung inline auf der Webseite auszugeben und eine freundliche Nachricht zu erhalten (definiert durch die Webparts selbst). oder eine Standardnachricht), die zur Laufzeit an den Benutzer ausgegeben wird, anstatt die gesamte Seite zu löschen.

Damals wussten wir von keiner solchen Lösung. (Ich immer noch nicht). Das Beste, denke ich, wäre, wenn etwas wie das, was ich gemacht habe (die Datei ist enthalten), in das ASP.Net-Framework aufgenommen wurde. (Wenn einer von euch ASP.Net-Jungs das liest: Fühlen Sie sich frei, meinen Code zu stehlen. Es würde besser funktionieren, je höher es in der Klassenhierarchie ist Es könnte zum Beispiel ein Teil von System.Web.UI.WebControls.WebControl sein, mit einigen web.config Einstellungen könntest du zwicken um es zu aktivieren ... es würde helfen, während der Entwicklung zu haufen .. zumindest würde es mir helfen :))

Also, zu der Lösung, die wir beendet haben mit: Ich habe ein BaseWebPart erstellt, von dem alle anderen Webparts (die mit Unterbrechungen stürzten) übernommen werden. Wenn geerbt, würde das BaseWebPart sicherstellen, dass ein try / catch alle Aufrufe aus dem ASP.Net-Framework (Render, CreateChildControls usw.) umgab, so dass ein Absturz in einem dieser Fälle gut verarbeitet wurde. Jeder Webpart könnte dann eine Methode mit dem Namen HandleException überschreiben, um zu steuern, was passiert ist, wenn es abgestürzt ist. Das Standardverhalten (wenn sie nicht überschrieben wurden) wurde auf

render das Stacktrace im Debug-Modus oder render eine Standardfehlermeldung im Freigabemodus

Um jeden Framework-Aufruf mit Ausnahmebehandlung zu umbrechen, Wir hatten einen zweistufigen Ansatz, in dem

1. Die erste Stufe (ExceptionHandlingWebPartBase) überschreibt und verschließt Methoden,
 
2. wendet dann try / catch auf eine neue Gruppe von Methoden an, Parameter der Weiterleitungsmethode
 
3. Diese neuen Methoden werden in der zweiten Ebene (BaseWebPart)
überschrieben  
4. , wo sie versiegelt werden und ein Aufruf an neue virtuelle Methoden erfolgt, die dieselben Namen wie die Framework-Methoden haben.
 
5. Diese Methoden (jetzt mit einem Catch-Block um sie herum) werden dann bei Bedarf in einem regulären Webpart außer Kraft gesetzt, der von BaseWebPart erbt. Die Ausnahmebehandlung ist somit für den Erben transparent.

Der einzige Nachteil dieses Moduls bestand darin, dass MOSS mehrere "Basis" -Webparts hat, von denen Sie erben würden, um Ihre eigenen Webparts zu erstellen. Daher musste dieses BaseWebPart einmal für jedes dieser Elemente dupliziert werden. Wir wollten diese Funktionalität auch für Web-Steuerelemente, Also mussten wir den Code im Grunde kopieren, um auch ein BaseWebControl zu erstellen. Wenn dieses Fehlerbehandlungsmodul höher in der Hierarchie enthalten wäre, beispielsweise in WebControl oder Control, würde einmal ausreichen, um alle verschiedenen Fälle abzudecken. Leider erlaubt c # keine Mixins, sonst wären wir wahrscheinlich in der Lage, die Exception-Behandlung auf einen Schlag auszuführen. So wie es aussieht, wurden 4-5 Klassen von doppeltem, identischen Code den 40-50 Klassen mit duplizierter Ausnahmebehandlungslogik vorgezogen.

"Hat es funktioniert?" du fragst? Nun, die Vorteile, die sich aus dieser Konfiguration ergaben, beinhalteten

1. Es ist nicht notwendig, während des Tests Hotfix-Testumgebungen zu erstellen
 
2. garantierte Protokollierung von Ausnahmen in der Produktion
 
3. eine allgemein nüchternere Fehlerklassifikation von den Testern (bevor sie nur sagen würden "alles ist unten, diese Seite funktioniert nicht - das ist nicht akzeptabel, Level 1 Fehler"
 
4. einige Ausnahmen in den Webparts schlichen sich in die Produktion, aber anstatt die ganze Seite zum Stillstand zu bringen, wurde eine freundliche Nachricht gezeigt, die uns viel Zeit bei der Behebung des Problems (nächste Version anstelle von Hotfix) einbrachte >

Ich verwende dieses Setup definitiv wieder, wenn ich das nächste Mal in einem Projekt mit vielen Webparts, Websteuerelementen oder benutzerdefinierten Steuerelementen bin.

und so weiter zum Code: