Error Handling

When the compiler reports a syntax error the error might not be on the line indicated. First check this and then if not check the preceeding line.

Try - Statements that might produce a run-time error
Catch - Statements to run if a run-time error occurs
Finally - Optional statements to run whether an error occurs or not

You can break out of a Try Catch statement by using the Exit Try keyword.

Try 
   Throw New OverflowException 

Catch e As Exception 

   e.message - to the user 
   e.tostring - if in Debug 
   e.gettype - if in Debug 

Finally 
'This is always executed

End Try 

Catching all Exceptions

Catch 
{ } 
Catch (System.Exception) 
{ } 
Catch (System.Exception ex) 
{ } 

public static void Static_MyMethod( 
   Excel.Workbook workbook) 
{ 
   try 
   { 
   ExceptionHandling.TracerAdd("METHOD", System.Reflection.MethodBase.GetCurrentMethod().Name + "start"); 

   } 
   catch (System.Exception ex) 
   { 
   } 
} 

Catching Specific Exceptions

Catch (System.DivideByZeroException ex) 

The Catch block is optional when a finally block is supllied
A more specialised catch block should come before a generalised one

ReThrowing Exceptions

Catch (System.Exception ex) 
{ 
   // do something with ex 
   throw; 
} 
or 
   throw new System.Exception("", ex); 

Do not throw an exception by passing just the exception object (eg throw ex;) because this loses stack trace information

Defensive Coding
Structured Exception Handling - this enables you to filter out and catch specific errors.

If the editor cannot correct the compile time error it will be underlined

Error List

Big improvement from VB 6 where you were told about errors one by one and you have to fix the current error before getting told about the other errors.

Option Explicit On - prevents you from using a variable that has not been declared (on by default)

Option Strict On - prevents automatic type conversion (eg Int32 into an Int16 - ie narrowing conversion)

Exceptions

A bug is a programmer mistake that should be fixed before the code is distributed.
An exception is not the result of a programmer mistake (although bugs can raise exceptions)
Rather exceptions are raised as a result of predictable but unpreventable problems that arise while a program is running.
An error is caused by a user action (errors can cause exceptions)
Whereever possible user errors should be anticipated and prevented.

Even if you remove all bugs and anticipate all user errors you will still run into unavoidable problems.
These are exceptions and they should be handled so they do not bring down or terminate your program.
Exceptions must be handled before the program can continue.

When an exception is thrown the CLR searches back through the stack until an appropriate exception handler is found.
If none of the calling functions are able to handle the error the CLR will handle the error by terminating abruptly.

Exceptions will be either of type System.Exception or of a type derived from this.

Exception Object

properties/methods
Message - information about the exception (read only)
HelpLink - link to a help file associated with the exception
StackTrace - this is set at runtime used to provide a stack trace for the error statement.