Application Security Testing: An Integral Part of DevOps
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:
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...
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
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:
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.
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.
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.
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:
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!