Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations TouchToneTommy on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Exception Management... 3

Status
Not open for further replies.

bmgmzp

Programmer
Aug 18, 2006
84
US
At my office we've migrated to Visual Studio 2005. We used to be heavy into Access and VB6. Does anybody have any advice on how to retrain my brain to better understand and implement exception handling / exception management? I'm afraid that i'm not fully comprehending this concept and that i'm still stuck in an Access / VB mindset when it comes to error handling. Are there any good books or web pages that deal just with exception handling?

Thanks
 
I too spent several days wrapping my head around exception handling and leaving the 'on error' world behind. Been in VB since VB3 and had to learn to walk all over again :)
Here is a starting point:
I have several more very good articles but they at at my home office right now. I will post them later when I get back home.
I also have a good wrapper class for your own exception class if you are interested.
 
Step 1) Forget everything you ever knew about VBA/VB6

I usually recommend that people who are looking to jump from VB6 to VB.Net go learn Java or C# first. VB.Net is functionaly identical to C#, but with a VB like syntax.

As for try/catch blocks, think of them like an if block and error handling all built into one.

Code:
Try
  'code to try to execute
  'if something goes wrong, and "exception" is "thrown"

Catch excTAE as threading.ThreadAbortException
  'we can catch specific error types

Catch exc as exception
  'catching an exception like this will catch all exception 
  'that have not yet been caught. Kinda like a "case else" 
  'in a select case block.

  'now that we have it caught, we can do things with the 
  'exception
  debug.write exc.message

Finally
  'Any code in finally will fire no matter what. 
  'Wether an exception is thrown or not, this code will 
  'run.

End Try

VB.Net Forum forum796 forum855 ASP.NET Forum
[monkey]I believe in killer coding ninja monkeys.[monkey]
 
Do you think it is still a best practice to put a default exception handler in every sub/function?

Code:
Public Sub Test()
     Try
     Catch ex as Exception
     End Try
End Sub

Even in this situation?

Code:
Public Sub Test()
     Try

          Try
          Catch exSQLException
          End Try

     Catch ex as Exception
     End Try
End Sub

 
If you really need to nest try/catch blocks, chances are that you should be calling a seperate function for the nested blocks. (it will also make your code easier to read)
When I layout my code I have very few exception handlers and let the exception bubble up to the entry point or the last code branch. An exception is something you are not expecting to happen and shouldn't be happening and usually means something really bad happened and you want to exit out of your code gracefully. By letting it bubble up to a single, or very few handlers you can centralize your error code.
If it is an exception that may happen but you don't want to short circut you code, for instance a database update in a loop. Just because 1 update fails you don't want to stop trying the others, make the DB update a seperate routine and put a try/catch block in that routine.
I have spent days laying out my exception handling architecture.
Just remember, exception handling is very expensive and sloooooooo
 
I have a decent number of nested try/catch blocks.

For instance, if I'm running a process, the entire process is encased in a general exception handler that will catch any unhandled exception, log the error, notify the user, and reset the GUI. But inside the process I could run into a time out exception while hitting the database. In that case I want to handle that exception and retry the database call. Or maybe I run into a bad value in some calculation, I can use the catch block to clear the value and continue on.

I also go the other way. At the begining of a lot of my reports I check to see if the parameters that were passed in are OK. If not, I can declare a new exception and throw it:
Code:
if selectedItem is nothing then
  dim exc as new exception("Invalid Selection")
  throw exc
end if

That exception will bubble up to the general handler, notify the user and reset the GUI for me.

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
[monkey]I believe in killer coding ninja monkeys.[monkey]
 
I'm not familiar with EMS's .net framework, but I personally wouldn't invest in it. In VB6 were error handling was much more challenging systems like EMS were almost a basic requirement. But with .Net, if you build a solid application framework, you can wrap the exception handling right into it. No need for cumbersome 3rd party tools.

In our applications here we have a general library. That library contains abstract classes that handle all of the data interaction (data access layer) and process functionality (business layer). These classes are inherited by other classes that are specific to some function or data element.

So we have a BaseThreadTracker class. BaseThreadTracker handles all of the threading, default public method, and common functionality. BaseProcess is inherited by BaseReport, BaseLetter, and BaseProcess. They take that threading code and expand on it to specifically work on Crystal Reports, Word merge letters, or general processing respectively.

Each of those classes is then inherited by classes like rptUsage, ltrCollection, and prcTaxCodeUpdate. These classes take that code designed for Crystal or Word and what not, and apply specific business rules and output based on the desired functionality.

It took a good amount of time to get this system hammered out to this point, and there is still more I want to tweak and add to it. But it allows us to take a set of business rules from the users, and turn it into a usable product in very little time. We don't have to worry about threading code, or logging, or GUI control or any thing like that, we just focus on the business rules and the system takes care of everything else for us.

Anyway, a full application framework can and will do everything that EMS can do with tighter integration and more functionality. But that's just my $0.02

-Rick

VB.Net Forum forum796 forum855 ASP.NET Forum
[monkey]I believe in killer coding ninja monkeys.[monkey]
 
I have to agree with Rick. I used to use DevPartner FailSafe for my VB6 error instrumentation. But now I have basic classes that are inherited in the Specific use classes and all the exception handling, process handling, logging etc. comes along for the ride. It took many, many hours of design and architecture planning but was well worth it. And like Rick those base classes are still being tweaked, but I can pound out a basic application very quickly and just focus on the business needs of the app.
Spend the time building your own application framework, you won't be disappointed.
 
I'm really appreciative of all the info, however my company doesnt have the time, or the manpower to write our own framework so we have to look to 3rd parties. Have you heard of any good 3rd party tools? I've heard of IdeaBlade but havent evaluated it yet.
 
I've never heard of IdeaBlade. As far as any others, I am in the dark. Sorry...
 
I know there are templates and frameworks available on the web. Search for DAL or Data Access Layer template sample VB.Net and the like on Google. Having a solid DAL will save you sooooo much time and effort over trying to dink arround with connections and query objects each time you need data.

There are likely some good samples/templates for factory class systems as well, but I don't know of any off the top of my head.

As for the time, don't underestimate the power of such a system. With our framework in place we can turn over a simple report from design concept to testing release in a matter of hours. And with the huge amount of reusable code, we have virtually 0 bugs with the interface and interaction of the application.

-Rick



VB.Net Forum forum796 forum855 ASP.NET Forum
[monkey]I believe in killer coding ninja monkeys.[monkey]
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top