Handling Exceptions in Visual Basic

Introduction

Hello and welcome to today's article. Today I will talk about Exceptions and how to handle them properly in Visual Basic.

Exceptions, What are They?

Simply put: an Exception is an error - something that wrongfully happens in your program. If used properly, exceptions can become close friends. There are mainly three types of exceptions:

  1. Compile time exceptions

  2. Logic exceptions

  3. Run time exceptions

At the end of the day, the area you need to spend the most time on is run time exceptions. Why do I say so? Well, as a developer you need to address any possible error in your application. It may seem obvious, but there are numerous errors that can occur at any given point in your app. With proper planning, you should be able to eradicate most of them; but it is only when you have properly tested your application where you encounter many an unforeseen error. Let me not get ahead of myself here, let me start at the top of the list.

Compile Time Exceptions

Compile time exceptions happen when you compile your application and the compiler informs you about certain errors. These errors may be any of the following:

  • Wrongly spelled objects. These are usually "spelling" errors. For example if you have an object named objValidate and you have referred to it in code as: objVlidate

  • Wrongly referenced Properties and methods. Again, these may be due to a spelling error, or when you have wrongfully referred to an object when you meant a different object. For example: Let me say you have two objects: objA and objB. Now, let me presume further that objA has a Property called Alphabetic and objB has a Property named Numeric. Now, it can get pretty confusing sometimes when you have hundreds of objects in your class(es) and somebody will eventually mix them up by referring to the Alphabetic Property of objB or Numeric Property of objA.

  • Creating objects incorrectly. This is quite common. Many a developer forgets to initialize their objects with the New keyword. It happens to the best of us.

  • Referencing obsolete objects. This happens when you refer to an object that was already disposed.

  • The list goes on, and I could probably go on forever as well, but you get the idea...

Logic Exceptions

Truth be told, this is not an exception where the compiler will tell you what went wrong; in fact, you won't know until the particular segment of code has been properly tested. How will you know? You will get the wrong results. Let me use a very simple example. Supposed you had a segment of code that is supposed to turn the Form's BackColor to blue (this is a piece of code where you have to physically see the results for yourself), but your code kept on turning the color to red. This is a logic error. This means that you have to change the logic of your code in order to get the desired result.

Run Time Exceptions

Bad news. Users aren't perfect and neither is your program. The sooner you accept these two facts, the sooner your apps will be built better. In the planning phase of your app, you must prepare for most of the errors the user may encounter. These include, but are not limited to the following:

  • Attempting to read a file at the wrong location or a file that doesn't exist

  • Network problems

  • Drive problems

  • Expecting a numeric value when an alphabetic value has been entered

  • Division by 0

  • Having insufficient privileges to complete a certain task

  • Normal validation problems

The above list may seem obvious to most experienced developers, but inexperienced developers tend not to plan properly.

This brings me to the question: How do I handle exceptions properly?

Try and Catch blocks.

Try, Catch and Finally Blocks

'Try/Catch/Finally' statements are used for structured exception handling. Structured Exception Handling is a term used to describe the process that can be followed whilst coding. The structure may be broken down as follows:

Try

You put all your code that you need to run inside the Try Block. The compiler will then attempt to execute the code inside the Try block until an exception occurs, if ever.

Catch

In the event of an exception, the Catch Block will catch the error or errors and attempt to handle them successfully. This is where you will handle your exceptions. Do not think that you can handle all the errors with one Catch statement, as you cannot. The trick is that you have to handle each exception individually, as each exception is ultimately different than the others.

Finally

A Finally block assists in cleaning up your resources and disposing of the necessary objects.

An example of a proper Try/Catch/Finally statement looks as follows:

    Private Sub GenDWMCalc() 'Check If Duration Expired
        Try
            Dim DateGen As Date
            DateGen = CType(DateReg, Date) 'Date From Registry

            Select Case GenPeriodReg
                Case "Day(s)" 'Day(s)
                    If DateDiff(DateInterval.Day, DateGen, Now) >= GenDurReg Then 'If Today's Date > Than Registry Date
                        RandomAllGenie() 'Randomise
                    End If
                Case "Week(s)" 'Week(s)
                    If DateDiff(DateInterval.Day, DateGen, Now) >= (GenDurReg * 7) Then '* 7 For Week
                        RandomAllGenie()
                    End If
                Case "Month(s)" 'Month(s)
                    If DateDiff(DateInterval.Month, DateGen, Now) >= GenDurReg Then
                        RandomAllGenie()
                    End If
            End Select

        Catch df As DateFormatException
            MessageBox.Show("Date In Wrong Format!")
        Catch ae As ArgumentException
        	MessageBox.Show("Missing Arguments!")
        Catch ua As UnAuthorizedAccessException
        	MessageBox.Show("You Do Not Have Sufficient Privileges For This Task!")
        End Try
    End Sub

Here, there might be a potential of three different exceptions, or more. Each exception has been handled individually - although not super-duper classy, but the point still remains that you should not handle all exceptions the same. Why?Well, look at the type of exceptions handled. There was an exception for the wrong date format, an exception for the wrong number of arguments received as well as an exception for not having appropriate privileges for this given task. Each of these exceptions vary not only by type, but in the way the particular problem should be handled, from each other.

Further Reading

Now that you know what exceptions are, and how to handle them, you may want to have a look at the next couple of articles:

Conclusion

Today I showed you how to handle exceptions. I hope you have learned from this article and that you will put your knowledge to good use. Until next time, cheers!



Related Articles

Comments

  • There are no comments yet. Be the first to comment!

Leave a Comment
  • Your email address will not be published. All fields are required.

Top White Papers and Webcasts

  • IBM Worklight is a mobile application development platform that lets you extend your business to mobile devices. It is designed to provide an open, comprehensive platform to build, run and manage HTML5, hybrid and native mobile apps.

  • Best-in-Class organizations execute on a strategy that supports the multi-channel nature of customer requests. These leading organizations do not just open up their service infrastructures to accommodate new channels, but also empower their teams to deliver an effective and consistent experience regardless of the channel selected by the customer. This document will highlight the key business capabilities that support a Best-in-Class customer engagement strategy.

Most Popular Programming Stories

More for Developers

Latest Developer Headlines

RSS Feeds