Visual Basic Error HandlingVisual Basic - Error Handling
On Error GoTo Hell
A Methodical Approach to Error Handling
Inconsistent as it is, try to mimic Visual Basic's own error handling scheme as much as possible.
Use line numbers in your source code.
Raise exceptions when possible because return values will be ignored.
Automatically log critical MsgBox errors.
Have an error handler in every routine.
Write meaningful error logs (to a central location if possible).
Use assertions.
Don't retrofit blind error handlers.
Trace the stack.
Use a ROOS (Resource Only OLE Server).
Replace useful intrinsic objects with your own.
Check DLL version errors.
Use Microsoft System Information (MSINFO32.EXE) when you can.
Treat error handling like transaction processing.
Don't test your own software or write your own test plans.
Stress test your applications.
Use automated testing tools.
Consider error values.
Tighten up Visual Basic's type checking.
Define constants using a TypeLib or an Enum.
Keep error text in a resource file.
Always handle errors in controls and components (that you build).
Use symbolic debugging information.
Handling errors properly in Visual Basic is a good idea because of the alternative: Visual Basic's default error handling rules are rather severe. Unhandled errors are reported, and then an End statement is executed. Keep in mind that an End statement stops your application dead?no form QueryUnload or Unload events, no class Terminate events, not much of anything in fact.