One very common requirement for migration projects is to adapt certain error handling patterns used in a customer’s Visual Basic 6.0 code to the structured error handling provided by .NET, cleaning up the code, improving its maintainability, and, whenever possible, complying with .NET best practices.

The VBUC already converts several commonly used error handling patterns, such as the ones described in this old post. There are, however, situations where the VBUC is not able to recognize a pattern. these usually involve Goto statements, On Error Resume Next, Resume Next or some other construct usually associated with “spaghetti code”. When one of these patterns is encountered, the VBUC does a very basic transformation and generates an EWI so it can be cleaned up through manual intervention later on, such as in the following example:

Private Function <NAME>(<PARAMS>) As <TYPE> 
  Const MethodName As String = "<NAME>" 
       On Error GoTo ErrorLabel 
       <STATEMENTS 1> 
       On Error GoTo <LABEL> 
       <STATEMENTS 2> 
  CleanUp: 
       <STATEMENTS 3> 
       Exit Function 
                
  <LABEL>: 
       <STATEMENTS 4>       
       LogError(MethodName) 
       Err.Raise 16, , MethodName 
                
   ErrorLabel: 
       <STATEMENTS 5> 
       LogError(MethodName) 
       Err.Raise Err.Number, , MethodName 

End Function 
 

private <TYPE> <NAME>() 
{ 

const string MethodName = "<NAME>"; 
//UPGRADE_TODO: (1065) 
         Error handling statement 
         (On Error Goto) could not be converted. 
         More Information: 
         http://www.vbtonet.com/ewis/ewi1065.aspx 
   NotUpgradedHelper.NotifyNotUpgradedElement(
      "On Error Goto Label (ErrorLabel)"); 

<STATEMENTS 1> 
try 
{ 
       <STATEMENTS 2> 
       <STATEMENTS 3> 
       return result; 
} 
catch (Exception ex) 
{ 
       <STATEMENTS 4> 
       LogError(MethodName); 
       throw new System.Exception(
              ((int) 16).ToString() + 
              ", " + String.Empty + 
              ", " + MethodName); 
        
ErrorLabel: 
       <STATEMENTS 5> 
       //UPGRADE_WARNING: (2081) 
         Err.Number has a new behavior.  
         More Information: 
         http://www.vbtonet.com/ewis/ewi2081.aspx 
       LogError(MethodName); 
       throw new System.Exception(
              Information.Err().Number.ToString() + 
              ", " + String.Empty + 
              ", " + MethodName); 
       return result; 
} 
} 

Most of the time it is possible to generate a solution that will correctly convert the error handling pattern, maintaining functional equivalence and meeting any additional coding guidelines from our customers. For the previous example, The VBUC can be customized so the generated code looks as follows:

try 
{ 
       try 
       { 
              <STATEMENTS 1> 
       } 
       catch (Exception ex){ 
              <STATEMENTS 5> 
              throw; 
       } 
       try 
       { 
              <STATEMENTS 2> 
       } 
       catch (Exception <LABEL>Ex) 
       { 
              <STATEMENTS 4> 
              <LABEL>Ex.Data.Add("ERROR",16); 
              throw; 
       } 
} 
finally 
{ 
       <STATEMENTS 3> 
}

This example makes some assumptions on the nature of the code and on the intention of the original VB6.0 developer, in particular:

• Errors raised by  <STATEMENTS 1> should be handled by <STATEMENTS 5>
• Errors raised by  <STATEMENTS 2> should be handled by <STATEMENTS 4>
• <STATEMENTS 3> is cleanup code that should always be executed
• The Exception needs to be thrown again without loosing any information

This is just an example, but the intention is to show what type of customizations can be done. The VBUC transformation engine is very powerful, and, as long as a pattern can be identified, can help you automate the solution to most VB6.0 problems.