Visual J# Exception Handling for the Debugger 

This topic explains setting exception handling for the debugger and provides background on why exception handling needs to be set.

Note

See Visual J# Exceptions to examine a list of .NET Framework exception equivalents.

Setting Exception Handling in the Development Environment

The Exceptions dialog box, under Common Language Runtime Exceptions, includes the category Java Language Exceptions. Some exceptions under this category have equivalents in the .NET Framework. This means that when you change the handling for a Java-language exception, you must also change the handling for the equivalent .NET Framework exception to get the same behavior as per Java-language exception semantics. This is because an exception thrown at run time can originate either from the class libraries included with Visual J#, or it can originate from the underlying .NET Framework common language runtime layer.

Why Exception Handling Needs To Be Set

If any exception-handling code exists, the Visual J# compiler emits the appropriate instructions to map the .NET Framework exceptions to the corresponding class library exceptions. The exception handler code is executed for both the Visual J# exception, and the corresponding .NET Framework exception is thrown. However, the debugger is not aware of this mapping. Hence, if you want to break on an uncaught exception, or when an exception is raised, you must change the handling for both the class library and the corresponding .NET Framework exceptions.

Example

To illustrate, look at the following code in Visual J#:

public void caller()
{
   // Handler for Visual J# exception:
   try {
      stringize(null); // Will result in an exception at runtime:
   } catch (java.lang.NullPointerException nullEx) {
      // Compiler emits code 
      // to catch System.NullReferenceException also.
      nullEx.printStackTrace();
   }
}

public String stringize(Object o) {
   // Invokes method without checking for null.
   // Results in a System.NullReferenceException at run time.
   return o.toString();
}

When the stringize method is called at run time with a null parameter, it will result in a NullReferenceException . However, the compiler emits the code to handle both java.lang.NullPointerException as well as NullReferenceException . Hence, the user code is able to catch the exception in a transparent manner.

While debugging with Visual Studio, if you want to change the handling for exception on null value passed into the stringize method, just changing it for java.lang.NullPointerException is not sufficient. The debugger will encounter NullReferenceException at run time; therefore, the handling should be changed for this exception too.

You need to change the handling for both exceptions, because if the stringize method is in another class, it could also explicitly throw java.lang.NullPointerException. To take care of both possibilities, you need to set handling of both exceptions together.

See Also

Reference

Visual J# Exception Hierarchies

Concepts

Conditional Debugging Support