I began my run in the IT field back in 1975 while at the University getting my Industrial Engineer Bachelor Degree; using Wang Basic language and Burroughs 6700's FORTRAN and COBOL, working as a Teacher’s assistance for a fist full of dollars, since then I had worked in four different countries: Venezuela, USA, Mexico and Australia, the Business Basic Language the main skill expected from me; learning Unix, C, PASCAL, Uniplex, WordPerfect, 20/20 in the lates 80s, Sybase in the early 90s, Basis BBx in the 90s, Microsoft’s VBA in the mid 90s, Visual Basic version 3.0 around 1996; moved to Australia in the lates 90s, here I kept learning, Transoft’s Universal Business Language, Oracle, Microsoft SQL Server, Visual Basic .Net; working for a major Australian company in the building material market. I had worked for Computers Manufacturing companies (MAI Basic Four after reading the Wikepedia definition, it feels good being an active part of the industry), and high rollers companies (DOLE, Pepsico when they operated Pizza Hut, KFC, Taco Bell and PFS, Boral Limited), roaming the world while doing so, exposed to cutting edge technologies of their time, creating it when the opportunity required so. I currently look after an Oracle data warehouse, sourcing its data from four or five legacy applications, servicing Crystal Reports and Cognos Cubes, developed VB and Net solutions; I could claim the phrase “I had been there, done that” suits me like a globe, always addressing any challenge with an engineer mind, which is different to an IT mindset.
View all articles by Arnaldo Sandoval...
Everyone tries to write error free applications, but we all know end users are smarter than us, finding ways to break our well protected applications. Then we are given the answer "I don't know" when we ask the obvious question "What were you doing?", or "I can't find it" to our inquiry "Did you write down the error message?"
Messages like the one above may frighten end users. They may think it was their fault, preferring to hide any evidence from us, perhaps thinking "This guy is making a lot of money and wants me to look after his/her shortcomings".
NET FRAMEWORK EXCEPTION HANDLING
The .Net Framework provides several Exception Handling classes, We implement them here and there, We try our best to trap as many errors as we can, returning nice error messages to the user, like the one below:
All the .Net Framework classes derive from the SystemException one. It also provides the ApplicationException class as well. It is Microsoft's recommendation that we implement the ApplicationException class in our applications. This recommendation has triggered several discussions on the Internet with opinions in favour or against its usage. Joining this discussion is pointless, however there are links to some of them in the References section in this thread.
The code posted in this thread implements an Exception Handling class based on the suggested ApplicationException class, with some value added properties and method you may find helpful. It is coded in VB.Net 2003 as there are plenty of versions written in C#. It also includes a test project that checks the additional features implemented.
STRUCTURED EXCEPTION HANDLING (SEH)
In Barton Friedland's article .NET Anatomy - Structured Exception Handling in .NET he wrote "structured exception handling (SEH), a service built into the core of .NET and available to all languages supported by it. Since the infrastructure for this service is built-in, there is very little code required to take full advantage of these features." which is true and fascinating.
The .Net Framework's built-in Exception Services give us so much information about the environment of the process triggering it, plus additional information exposed by the .Net Framework itself, that we should be able to develop a robust Exception Handling "component" that we can use in all our applications.
Before getting to the detail of the Exception Handling Component, let's overview what the .Net Framework has to offer on this matter.
We all know about the Try-Catch-Finally-End Try error trapping block; it goes like this:
| Public Sub MyMethod() |
' Code before the Try-End Try block
' You application code goes here
Catch se As SystemException
' Error handling code, or Exception Handling code, basically the same thing.
' Common block to perform some cleansing after the exception.
' Code after the Try-End Try block
Any error outside the Try-End Try block will trigger an untrapped exception. If the method (MyMethod) is outside a Try-End Try block itself, the exception will escalate, and if nobody catches it, your application will crash, returning an ugly message like this one:
Knowing this, you would try to put you code inside a Try-End Try block, wouldn't you? Well, there is another discussion on the internet regarding the usage of Try blocks, this one focusing on the performance impact of exception trapping in .NET. Once again, Barton Friedland's article has a nice explanation about the way exceptions are handled in the .NET Framework. A point not documented in these discussions is the overhead that occurs when your application triggers an exception.
Returning to the example, this time using more meaningful code,
| Private Sub Button4_Click(ByVal sender As System.Object, _ |
ByVal e As System.EventArgs) _
Dim a As Integer
Dim b As Integer = 5
Dim c As Integer = 0
a = b / c
Catch e1 As SEHComponent.ErrorHandlingException
'Catch se As SystemException
' MessageBox.Show(se.Message, "System Exception", _
' MessageBoxButtons.OK, _
The Button4's click event will trigger an Arithmetic Exception because there is a division by zero. The exception will go untrapped because the Catch we are using is expecting an SEHComponent.ErrorHandlingException exception. Implementations like this will crash out with a message like this:
The Exception coded on the first (and unique) catch is not designed to process OverflowExceptions, We can improve the code by removing the comments for the second catch.