How to handle errors in an n-tier application?

I struggled with this from day one. It probably doesn't help that I'm surrounded by a lot of code that doesn't even handle errors at all.

Anyway, I work with WebForms in your traditional n-level design: UI-> BLL-> DAL. Usually what I do (and I know it is not) is to try / catch my data operations. If there is an exception, I just throw it in the bubble.

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

So, it bubbles up to BLL, and there is another try / catch in it where I will log the error. Now I want to warn the user that something is wrong, so I drop it again, so it bubbles up with the user interface. At the user interface level, I will complete the / catch attempt, and if an error occurs, I will show them a friendly message.

What are your thoughts? What can I do better here?

+6
error-handling webforms
source share
3 answers

As I understand it, you have three attempts / catches - one for each level: DAL, BLL, UI.

You should only catch when you are going to do something.

From what I understand, you just exit DAL, so there is no need for it.

You are registering exeption from the BLL, and this is good practice, as you will be able to collect exception data to ultimately improve the application.

Then you will understand at the UI level to translate the exception into something user-friendly. This is normal.

Therefore, I would get rid of try / catch from the DAL level - if you really are doing nothing but fixing the exception.

In some scenarios, it may be useful to add an identifier to the BLL, which is passed to the user interface exception and shown to end users, so if they call for support, personel support can map the identifier to the exception on the server.

This can be done, for example, by adding Guid or something else meaningful and unique to the Exception.Data collection.

+5
source share

Unlike other answers, I am going to advise removing try / catch from your user interface. Your BLL should catch the exception, register it and then provide some mechanism for the user interface to request what errors have occurred.

The result is a much cleaner UI code, since you don’t need to list all the possible exceptions that the business layer might throw. You can simplify your user interface code:

 if (businessObject.doSomeOperation == true) { // Do whatever you need to here. } else { // output error message from businessobject // something like businessObject.LastErrorMessage(); } 
+2
source share

you need to throw an exception and catch in the user interface, for example ... In BLL

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

Catech - Run in the user interface and show a user friendly message.

  if (e.Exception != null) { if (e.Exception.InnerException.Message == "ActiveRecord") { //Show here User freind message } } 
+1
source share

All Articles