Error Handling with Code ported from VB6: Throw or return codes

[Rodger]

Hello,

we are porting over 300.000 lines of code from VB6 into VB.NET.

The application is a very complex bookkeeping program having much technical booking logic, developed over many year from different programmers using different programming styles.

I am involved with writing the coding guidelines, and the most difficult of all is the error handling.

In the massive VB6 application all types of error handling were used, and in some places no error handling at all.

In VB6 'On error goto' and 'On Error Resume next' is used, having a single door out at the end of the program.

In some places err.raise was used to cause the program logic to throw control into some other routine. Layer after layer of such coding has caused a huge amount of combination errors where the error messages often are no longer correct.

Here is what I think would be the best, but I would like to know from some others having similiar experiences if it is the best way to go.

1. Do not use Throw and err.raise, but instead use integer return codes after catching the errors
2. Always check the return status to assure the function completed properly and to know how to handle the exception. I
3. Pass the control to the end of the routine (methods) and return to the routine the error code.
2. Display any system error messages (Old: Parameters identifying the procedure where the error occurred; New: exception.tostring) in the routines where the error occurs. (The programs are written in such a way that only critical exceptions occur)
3. Have for the application a general error handler, and then for certain Forms a form specific Error handler to catch any unexpected exceptions and return control to the initial state of the application / form.

Can anyone who has had experience with large amount of ported code from VB6 give me some advice?

Rodger




In the future we wish to take advantage of the VB.NET Try / Catch error handling.
functionality than probably any other

 

[Herman]

What I would do if you are going to rewrite anyways, is rewrite the exception handling as well. Just redo every function functionally compatible with the old ones, but use proper try...catch blocks with calls to a central error handler. I think you have #5 backwards though. You want to catch and handle only exceptions you DO expect, make sure to redirect all the rest to some logging facility or error feedback system.

 

[Rodger]

Herman,

thanks for your reply. Over the years we will slowly rewrite the error handling, but with 300.000 lines this would take many months, maybe years to do it at once.

Concerning new code and new development in new classes / libraries, I have some ideas that I would like to ask, ideas that seem to make sense, but that I have never yet tried.

My plan:
In the new class library
1. Not bother catching any critical errors.
2. Only catch expected errors which do not have an effect on the functionality being carried out correctly.

In the presentation projects (Winforms and ASP.NET)
1. A general error handler catching any mistake showing and logging any error and cleaning up any transactions with rollback, returning control to the main screen.
2. A Form error handler catching any mistake occurring while in the form which cleans up the same as #1, but returns control to the specific open form.
3. In some instances, an event (Examp. button, menu screen item, etc.) error handler catching any mistake which catches any mistake while complex functional routines are executing.

Do you have any experience with such error handling?

Rodger Dusatko