Wie werden Fehler in einer n-Tier-Anwendung richtig behandelt?

Question

Ich habe damit seit Tag 1 gekämpft. Es hilft wahrscheinlich nicht, dass ich von viel Code umgeben war, der überhaupt nicht mit Fehlern überhaupt klarkommt.

Wie auch immer, ich arbeite mit WebForms in Ihrem traditionellen n-Tier-Design: UI-> BLL-> DAL. Normalerweise tue ich (und ich weiß, dass es nicht stimmt), meine Datenoperationen zu versuchen. Wenn es eine Ausnahme gibt, schmeiße ich sie einfach zur Blase.

try 
'db operations 
catch ex as exception 
throw 
finally 
'close connections 
end 

Also dann sprudelt es den BLL und dort ist ein weiterer try/catch, wo ich den Fehler protokollieren werden. Jetzt möchte ich den Benutzer darauf aufmerksam machen, dass etwas nicht stimmt, also werfe ich es erneut, auf diese Weise brennt es auf die Benutzeroberfläche. Auf der Ebene der Benutzeroberfläche werde ich einen try/catch einfügen und wenn es einen Fehler gibt, zeige ich ihnen eine freundliche Nachricht an.

Was sind Ihre Gedanken? Was kann ich hier besser machen?

Answer 1

Wie ich verstehe, haben Sie drei Versuche/Fänge - eine für jede Stufe: DAL, BLL, UI.

Sie sollten nur fangen, wenn Sie etwas dagegen tun werden.

Von dem, was ich verstehe, Sie einfach von DAL retrow, so dass es nicht nötig ist.

Von BLL protokollieren Sie die Ausnahme und das ist eine gute Übung, da Sie in der Lage sind, Daten über Ausnahmen zu sammeln, um schließlich die Anwendung zu verbessern.

Dann fangen Sie auf der UI-Ebene, um die Ausnahme in etwas benutzerfreundliches zu übersetzen. Das ist ok.

So würde ich nur versuchen/fangen von der DAL-Schicht loswerden - wenn Sie wirklich nichts mehr tun, als die Ausnahme rückgängig zu machen. In einigen Szenarien kann es nützlich sein, einen Bezeichner an der BLL hinzuzufügen, der an die UI-Ausnahme übergeben und den Endbenutzern angezeigt wird. Wenn sie Unterstützung anrufen, kann die Supportperson die angegebene ID mit einer Ausnahme korrelieren das Protokoll des Servers.

Das kann getan werden, zum Beispiel, ein Guid oder etwas anderes sinnvoll und einzigartig zu Exception.Data Sammlung hinzufügen.

Answer 2

müssen Sie die Ausnahme und fangen in UI werfen, wie ... In BLL

try 
     { 
      //your code 
     } 
     catch (System.Data.SqlClient.SqlException ex) 
     { 
      if (ex.Number == 547) 
      { 
       throw new Exception("ActiveRecord"); 
      } 
     } 
     finally 
     { 
      MasterConnection.Close(); 
     } 

Catech die execption in UI und zeigen benutzerfreundliche Nachricht.

Answer 3

Im Gegensatz zu den anderen Antworten, rate ich Ihnen, das try/catch von Ihrer UI zu entfernen. Ihre BLL sollte die Ausnahme abfangen, sie protokollieren und dann einen Mechanismus für die Benutzeroberfläche bereitstellen, um abzufragen, welche Fehler aufgetreten sind.

Dies führt zu viel saubereren UI-Code, da Sie nicht alle möglichen Ausnahmen aufzählen müssen, die die Business-Schicht auslösen kann. Sie können Ihren UI-Code wie folgt vereinfachen: