Welcome to my tutorial on Custom (Structured) Exception handling in VB.Net (C# version coming soon). In this tutorial we will look into at creating a Class Library to help with dealing with exception handling in a custom way.

As a developer all of us have the same goal, to write error free applications, but the chances of that are about the same as finding Bigfoot. As we all know, the end user will always find a way to break our applications, in ways we never thought of in the first place. We can ask them "What were doing when the error happened" and, across the board, the answer is always "I don't know." Then our next question, like we're trained robots, is "What did the error say", and we always get something from "It said something like <insert meaningless statement here>.", or "I'm not sure, I just clicked the OK button and tried to finish, great help huh.

Most applications give basic Microsoft designed and generated messages, like the one pictured below:



This kind of message is enough to scare most end users from ever using that application again, doesn't do much for customer loyalty. So I spent hours and hours thinking that there has to be a better way of handling exceptions that inevitably happen, no one is the "perfect" programmer, except for maybe Martyr2 . All the .Net classes derive from the SystemException, but it also provides the ApplicationException. It is Microsoft's "Best Practices" to inherit from the ApplicationException class rather then the SystemException when writing your own exception handling class.

Before asking, or stating your personal opinion, this is a discussion that has been raging for years and may never end, so I suggest you go with what you feel comfortable, I choose to inherit from System.Exception because thats how I feel comfortable. So now lets get into our Class Library for our own structured custom exception handling, bear in mind this is a long tutorial as there just isnt any shortcut to accomplish this.

First thing you need, as with all classes you create, you ned to add and inherit the particular Namespaces you need to accomplish the tasks of your class, in this case our custom exception handling, so now the Namespaces:



You will notice as we get into this class we have used the <Serializable()> , meaning this class can be Serialized, meaning it can be populated once and pass it from object to object without having to repopulate it, just deserialize it when you need to.

An exception has many, many properties, and as you know, when creating properties, whether they be ReadOnly or Read/Write, they all need their own variable, so now we're going to look at the variables we need for our Class Library, many which are instantiated once declared:



NOTE: You will once again notice I break my class files into different sections using the Region Keyword, this, in my opinion, makes it easier to find thing in a large class file, such as this one. This, of course, is a design decision of all developers.

Next thing we're going to look at are the properties themselves. In this class there are 16 variables, 15 ReadOnly and 1 Read/Write. We have the ReadOnly variables because this information comes straight from the Exception being trapped so theres no need to allow the developer to set them. The single Read/Write variable allows the developer to add text describing what they were doing in the method that caused the Exception to happen in the first place. First we will look at the ReadOnly, and this is information that can be extracted directly from the Exception itself:



Two of the properties, ApplicationCulture and ApplicationVersion both call functions, we will get to these functions later, then the properties will make more sense on how they're populated. The Read/Write property is the only that allows the developer to interject his own text into the exception object, something currently not available in the current .Net Exception Object:



Next thing we're going to look at is the Constructors of our Class Library class. Most classes need constructors in order to be initialized. In this class we have 6 constructors. 3 are recommended by Microsoft, the other 3 utilize items such as SerializationInfo and StreamingContext, which are used for deserializing Exception.

Instead of showing all 6 at once, Ill show the Standard[b]constructors, then the [b]Custom constructors. First the Standard:



If you notice, those are pretty standard constructors for an Exception class, now we look at the Custom constructors and they will seem to be somewhat different than the Standard once:



These are the constructors that allow the developer to interject his own words on what he has doing in the method when the exception occurred. Now we can get into the meat of our Exception handler, we can discuss the methods that actually make it work. The first method we will be looking at will allow us to get the base exception of an exception. In the hierarchal listing of exceptions, there can be an exception, but 3 levels down there lies the exception that actually caused the exception in the first place. So lets take a look at that method:



Here we Override the http://msdn2.microsoft.com/en-us/library/s...etBaseException. Overriding this in our class is what allows us to reach the Exception that was at the root of the Exception thrown. The next method we will be looking at is the [url=http://msdn2.microsoft.com/en-us/library/system.object.tostring.aspx]ToString()[/ur] Method. But in our class we will re overriding it so we can have the items we wish to have regarding the exception wee just trapped in it. Lets say that at the end of your code you have MessageBox.Show(ex.ToString()), it would contains all the Exception information we want since we over rote the base method, it looks something like this:



Notice here we take all the items we wish to have in the ToString() method, and have them in a comma delimited string, which we can parse at a later date if we chose to. The next method we have, which we over wrote as well, is call GetObjectData, which we use to serialize out Exception Object. We over write this method so we can add the items we wish to have in our serialized Exception object. Here we use the SerializationInfo Class to add all the data we have collected about out Exception to the Serialized object:



The next, and ;ast 4 methods, are the main ones, they're the ones we're using to actually use Reflection to dig as deep into the Exception object we have acquired to get all the information we can find, some of the information being the application version, and the application culture. The first method we'll look at is called GetAttributes, and this method drills down as deep as it can into the AssemblyQualifiedName to get as much information as possible before calling the GetAppInfo method:



In all of that code you will notice the >>, this is where it is calling this method. This methods main function is to retrieve the applications culture and version from the assembly. When I first write this Class Library last year this was one ugly method, so in time I have re factored it ti make it more readable. This method parses and splits looking for 2 main keywords Version, and Culture. So, lets take a look at the new re factored version:



In this method, like the one before, you will notice 2 sets of >>'s, these are the 2 functions responsible for parsing the string sent to them to look for both the version and culture of the application of the application that caused the exception. Notice I said the application, all of this is retrieving assembly information from the application that generated the exception, not the Exception item itself.

First, we'll look at the GetVersion function, which retrieves a string delimited with equals signs (=), and based on this, if it exists, it retrieves the culture of the application where the Exception occurred:



The next function, GetCulture is also passed a equals sign delimited string (=), if it finds the delimiter then it searches the string for the Applications version, in the same manner we search for the applications version:



Believe it or not, thats what i takes to do custom (structured) exception handling in VB.Net, but we're not finished yet. This last method is simply used to make sure all variabes are either emptied out, or reset to their defaults each time our exception class is initialized:



That is what it takes to do your own structured custom exception handling. I wrote this Class Library at home, but it is used is several applications, both web and Windows, at work. I do suggest one thing, if you are going to use this object for applications that have many (I mean 10,000+) concurrent users do what we did, this object was altered to simply trap the exception and passw a user friendly message back to the application, it then forwarded the exception information, via a custom MessageSchema.xsd I created (making it platform independant) to a Web Service that logged the Exceptions and send either emails or SMS's to the appropriate groups based on exception level, application and time of day.

What I did leave out of here is the logging of the Exception, this was done intentionally. All developers log differently, use different databases, and some even use network flat files, so leaving that asoect out gives you the opportunity to add your own finishing touches to a very powerful object that took weeks of research and coding to complete. Since this Class Library us under the GNU General Public License I will be distributing this class with this tutorial. With this license you can alter, modify, add or delete as you see fit, but the license file and license header must stay in tact at all times.

Thank you so much for reading, and I hope you found it useful & informative as I did while creating it. Happy Coding!
 PC_ExceptionHandler.zip ( 67.14k ) Number of downloads: 234