Neulich, als ich im Interview auftauchte, fragte mich der Interviewer, was der Zweck von global.asax ist. Ich habe gesagt, dass es bestimmte Ereignisse wie Session_Start usw. abfangen soll. Er hat dann gesagt, wie man die Ausnahmebehandlung in deinem Code durchführt. Ich sagte, wir verpacken die Anweisungen in try catch block. Er sagte dann, würden Sie dies für alle Button-Click-Ereignisse in Ihrem Code tun? Das ist so langweilig und wiederholend. Wo kommt OOP hier ins Bild? Er sagte, Sie sollten immer Fehler in Application_Error in global.asax finden. Ich sagte, OOP sagt nicht, dass Sie alle Fehler in diesem Fall erfassen sollten. Wir sollten immer bestimmte Ausnahmen abfangen, und das sollte in diesen jeweiligen Handlern sein. Wir sind während des Interviews in einen ziemlichen Streit geraten, und ich sagte geradeheraus, dass ich mit Ihnen nicht einverstanden bin.
Können Sie mir sagen, wie behandeln Sie alle Ausnahmen auf der Serverseite?
Vielen Dank im Voraus:)
Die kurze Antwort, die ich gefunden habe, ist, dass Sie so programmieren, wie Sie angewiesen werden, Code zu schreiben, auch wenn Sie nicht damit einverstanden sind, wenn Sie den Job behalten wollen.
Wenn Sie jedoch nur die Fehler in der Global.asax abfangen, verlieren Sie das lokale Debugging von Variablen und die fehlerfreie Fehlerbehandlung. Fehler, die in Global.asax behandelt werden, fallen im Allgemeinen nicht ordnungsgemäß aus.
Ich erfahre im Global.asax generell alle unbehandelten Fehler, aber für mich ist es nur so, als hätte ich keine Bremsen am Auto, weil es Airbags hat. (Ja, ich liebe Metaphern)
Der Schlüssel zu all dem ist die Unterscheidung zwischen Expected und Unexpected Exceptions. Während Sie Code schreiben, sollten Sie explizit Ausnahmen abfangen, von denen Sie erwarten, dass sie passieren können.
Perfektes Beispiel ist die Teilung. Sie teilen den Zähler durch den Nenner. Sie wissen, dass das Teilen durch Null eine Ausnahme auslöst. An dieser Stelle können Sie entweder die erwartete Ausnahme abfangen, die behandelt werden soll oder explizit werfen, bevor Sie auf die Ausnahme stoßen (was auch immer von Ihren Anforderungen diktiert wird). Die unerwartete Ausnahme kommt ins Spiel, wenn Sie einfach nichts getan haben.
Aufgrund der Art und Weise, wie die meiste Software geschrieben wird, ist die unbehandelte -Ausnahme für die Benutzererfahrung schlecht und leider die weit häufigere Art von Ausnahme. Sie werden durch häufigen Code-Churn, mangelndes Verständnis der Anforderungen, begrenztes Wissen über das Gesamtsystem und etwas durch reine Faulheit eingeführt. Wenn sie auftreten, führen sie oft zu abrupten Änderungen der betrieblichen Aspekte der Software.
Der Zweck eines globalen Ausnahmebehandlers ist es, den Benutzer korrekt wiederherzustellen oder den Benutzer darüber zu informieren, dass etwas schiefgelaufen ist, während er so viele wertvolle Informationen wie möglich sammelt./ Ich persönlich finde, dass diese Ausnahmen auf sinnvolle Weise protokolliert und behandelt werden sollten so bald wie möglich. Wenn sie gefunden werden, ist es wahrscheinlich, dass entweder eine erwartete Bedingung nicht durchgesetzt oder behandelt wird oder dass ein logisches Problem im Code vorliegt, das die Anwendung in einen ungültigen Zustand versetzt.
Bei richtiger Verwendung ist ein globaler Ausnahmebehandler ein großartiges Sicherheitsnetz, mit dem die Qualität des Codes insgesamt verbessert werden kann. Das Risiko besteht in der Regel darin, dass man sich entweder nur auf einen globalen Exception-Handler verlässt oder nicht darauf reagiert, was berichtet wird.
Sie sollten nur dann Fehler finden, wenn Sie etwas über sie machen können (anstatt sie nur zu protokollieren), was ziemlich selten ist.
Zum Beispiel ist es sinnvoll, SqlExceptions zu versuchen, Deadlocks erneut zu versuchen:
Es ist nicht sinnvoll, jede Ausnahme in den Handler-Methoden Ihrer Seiten zu erfassen, wenn Sie diese Ausnahmen nur protokollieren und eine generische 'aw snap' Nachricht anzeigen. Setzen Sie diesen Code stattdessen an einen Ort: Application_Error .
Um mit Problemen umzugehen, die Sie erwarten können (wie Fehler durch Division durch Null), sollten Sie ungültige Eingaben von vornherein verhindern oder die Bedingung behandeln, bevor eine Ausnahme erzeugt:
%Vor%Eine Option besteht darin, dass alle Seiten in Ihrer Site eine Page-Klasse erweitern, die das Error-Ereignis von System.Web.UI.TemplateControl behandelt.
Application_Error ist nützlich, wenn Sie nicht alle Seiten Ihrer Site auf eine gemeinsame Basisklasse erweitern können.