Exception Handling in a N tier application visual basic 2015

I'm moving from vba to vb.net.
I have a 3 tier application - UI, BLL and DAL.

How is the best way to handle Exceptions?

I Know how to catch and throw them.
I have set up a Centralised Exception handler

At what point should I log the Exceptions?
Where they are thrown or in the UI?
If Where they are thrown then how do the Upper Layers know that the exception has been logged so I don't get duplicates?

It seems far easier to do all the Logging in the UI, This is being done by calling a Shared Sub in the BLL.
Is this Bad Practice?

I am looking to log the exceptions in the database and if that fails (No Connection to Database) then write to a Text file Log.
p-platerAsked:
Who is Participating?
I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

kaufmed   ( ⚆ _ ⚆ )I asked the operating system what I could do to become a better programmer. It said, "Let me give you some pointers."Commented:
I typically capture and log the exception at the top-most level of the service/business layer. This area then reformats the error into a more friendly message that gets passed back and displayed by the UI layer. The benefit of this is that if you ever switch UI technologies, you don't have to redo the exception logic; you only have to display the friendly message.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
p-platerAuthor Commented:
Thanks
So do you display a message box from the BLL?
Or how do you get the Message from the BLL to the UI?

Do you still have Try...Catch in the UI at all?
p-platerAuthor Commented:
Also a Good point about Switching UI as I will be changing from winforms to WPF in the near future
Become a Microsoft Certified Solutions Expert

This course teaches how to install and configure Windows Server 2012 R2.  It is the first step on your path to becoming a Microsoft Certified Solutions Expert (MCSE).

Learn More!
kaufmed   ( ⚆ _ ⚆ )I asked the operating system what I could do to become a better programmer. It said, "Let me give you some pointers."Commented:
So do you display a message box from the BLL?
You don't. A message box is a UI concern.

Or how do you get the Message from the BLL to the UI?
You have some property on your DTO/model that holds error messages. In the UI layer, you read the messages from that object and display them on the screen.

Do you still have Try...Catch in the UI at all?
I try not to, but sometimes it's unavoidable. It all depends on what your design is.
Jacques Bourgeois (James Burger)PresidentCommented:
First of all, your link to my article about centralized exception handling has an extra http://www.http.com// prefix that leads nowhere.

An exception is... exceptional. Unexpected exception are... unexpected. So, as so many things in programming, the answer to your question is that it is a case by case decision.

You can usually deal with some kind of exceptions right at the point where they occur, without having to log it, if you took the time to consult the documentation for possible exceptions and see that this specific exception could happen in that specific place. Problem solved, End Try and we go on.

Naturally, this is not always possible, because the correction sometimes requires some kind of intervention from the user, such as when a value is not correct for the field for which it was entered. You do not necessarily need to log these, because a message as to what is expected could be sufficient. This is usually best handled at the UI level, because using the same business layer, the message to display to the user can be different from one application to another, from one user (administrator) to another (guest). So, in the data access layer and/or the the business layer, this is usually:

Catch
   Throw

The exceptions that need to be logged are the unexpected exceptions, the ones that cannot be treated without intervention from the user, the ones that the user cannot correct by himself, or the ones that you thought would never occur.

I would almost (almost and usually are always part of these types of discussions) never do anything about these in the business layer, not even the UI. What can I do? I did not expect it. Sending the error message provided by the exception object to the user is most of the time more confusing than anything.

So, once again:

Catch
    Throw

It is was not treated anywhere down the line, it will eventually end up in my global error trap, and this is where it would be logged, and the application, most of the time, terminated, because a completely unexpected exception that is able go through all the previous steps could play very bad tricks on the data or the system.
p-platerAuthor Commented:
Sorry - i should have tested the Link I pasted.

So with the centralized Exception Handling I don't need to have Try... Catch everywhere in the UI (Only where I can deal with the exceptions and move on) as any Unexpected Exceptions will be Handled by this  Handler.

kaufmed
What do you mean by a property to hold error messages?
Below is a sample I have that produces an error by calling a Database procedure that doesn't exist

It checks the Error for either a Transaction Deadlock or a String Truncation error - It handles these then records and throws for all other errors

    Private Sub Button1_Click(sender As Object, e As EventArgs) Handles Button1.Click
        Try
            DatabaseErrorTestBLL.Save(25, "NoName")
        Catch ex As SqlException
            If ex.Number = 1205 Then
                MessageBox.Show("Transaction Deadlock. Please Re-run the Transaction.")
            ElseIf ex.Number = 6234 Or ex.Number = 7720 Or ex.Number = 8152 Or ex.Number = 35478 Then
                MessageBox.Show("Data would be Truncated. Please check the Length of the Data and Re-run the Transaction")
            Else
                MessageBox.Show("Connection to the Database has been Lost. The Application will now close")
                ExceptionRecorder.NewRecord(ex)
                Throw
            End If
        Catch ex As Exception
            MessageBox.Show("Connection to the Database has been Lost. The Application will now close")
            Throw
        End Try

    End Sub

Open in new window


The Save Sub that throws the Error
Public Class DatabaseErrorTestBLL
    Shared Sub Save(ByVal staffNo As Int32, ByVal name As String)
        Try
            DataBaseError.Save(staffNo, name)
        Catch ex As Exception
            Throw
        End Try
    End Sub
End Class

Open in new window


I then Record the Error with
Imports System.Data.SqlClient
Public Class ExceptionRecorder
    Shared Sub NewRecord(Ex As Exception)
        ExceptionRecorderData.save(Ex)
    End Sub

    Shared Sub NewRecord(Ex As SqlException)
        ExceptionRecorderData.save(Ex)
    End Sub
End Class

Open in new window


Where would I add a Property and How Check it?

Thanks All
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Visual Basic.NET

From novice to tech pro — start learning today.