(How)
C^# You Are - 17 February 2008

This week's questions revolve around debugging exceptions in code.

1. While running your application you get an exception. You were not running in the debugger so you don't know what happened. You do have the exception information because of logging. Where should you start looking?  Answer

   There are two pieces of critical information that all exceptions contain: the error and the stack trace. The error identifies (normally) what went wrong. If the exception is ArgumentNullException, for example, you know an argument was null. If it was InvalidOperationException then you know your code executed something that was unexpected.

   The stack trace tells you where the exception occurred. Unless you are running under the debugger, this is the only way to identify where the failure occurred. There are many questions in the forums where someone gives an entire method along with the exception object and asks for help identifying where it is failing. Use the stack trace for this. Depending upon the configuration you are running it can pinpoint the line where the exception occurred or just the general method.

   After the error and stack trace you can look at the message and any custom parameters the exception might have. The message might indicate more information about what went wrong for generalized exceptions (like ArgumentException. It never hurts to at least glance at the message.

   The custom parameters for an exception provide additional information that might help you narrow down the failure. For ArgumentException-based exceptions this would include the argument that caused the exception. For other exception-types it might include details about the state of the method/type when it failed. Use the message and custom parameters to narrow down the problems.

   The final piece of information is not available from the exception object. Instead it requires that you run the application and get a snapshot of the system when the exception occurs. This is critical for exceptions that do not occur often.

2. You have a rather complex application. Within your application you track employees in a compant. The following code normally works but it periodically fails with a InvalidOperationException. What is probably wrong?  Answer
   
   
   public Employee[] GetEmployeesByDept ( int deptId )
   {
      Collection<Employee> emps = new Collection<Employee>();
      foreach(Employee emp in emps)
      {
         if ((emp != null) && (emp.Department.Id = deptId))
            emps.Add(emp);
      };
   
      Employee[] arr = new Employee[emps.Count];
      emps.CopyTo(arr, 0);
      return arr;
   }
   
   

   When you are dealing with collections and you get a InvalidOperationException you should assume an enumeration failed because the underlying collection changed. All the built in enumerators are set up such that if the collection changes during enumeration they will throw the exception. Use the exception instance to examine the call stack. If the exception occurred inside the enumerator code then this is the problem.

3. While running your application you get a ArgumentNullException periodically. The particular method that raises the exception is called many times so you do not have a clear idea of what is causing the problem. Your application uses high-level exception blocks to trap all errors so the debugger never breaks in when the exception occurs. How can you debug this?  Answer

   The debugger is your friend here. The quick and dirty solution is to temporarily disable the high-level exception block (which generally isn't a good idea anyway). But this is sometimes infeasible so there should be a better way.

   For exceptions that occur only rarely you should use the debugger's Exceptions window to help narrow down the problem. Within this window is a list of many of the exceptions and RTL errors that can occur. By default the debugger will break as soon as an unhandled exception occurs. The key here is "unhandled". If you have a high-level exception block then there are no unhandled exceptions (in theory). The Exceptions window allows you to break into the debugger when an exception is thrown.

   To break into the debugger when a particular exception is thrown (irrelevant of whether it is handled or not) open the Exceptions window (Ctrl+D,E - by default). Scan down the list of exceptions/errors looking for the exception you want (in this case ArgumentNullException. Check the Thrown box and close the window. As soon as the exception occurs the debugger will immediately take control and allow you to diagnose what is going on.

4. While running some code you get an ObjectDisposedException. What is probably going on?  Answer

   Whenever you get an ObjectDisposedException you are dealing with an IDisposable object that was disposed (either implicitly or explicitly) and then used anyway. It seems to be a common misconception that checking for null is sufficient. A disposed object is not going to reset any variables to null. It is quite possible (and the general cause of this exception) that a disposed object is not null.

   Another common misconception is that keeping a disposable object in a class field is sufficient to keep it from being disposed. This is only partially true. When a garbage collection is done all objects are assumed to be freeable. Starting with root objects (statics) and the current stack contents the GC walks all objects looking for references to other objects. As it finds objects it marks them as in use. When it runs out of objects anything that has not been marked in use is freeable.

   A disposable object stored as a field in a class is only in use if the owning class instance is also in use.

5. The following code generates a NullReferenceException. What is going on?  Answer
   
   
   public class ControlWrapper
   {
      public ControlWrapper ( Control ctrl )
      {
         m_Control = ctrl;
      }
   
      public void DoWork ( )
      {
         m_Control.Text = ...;
         ... 
      }
   
      private Control m_Control;
   }
   
   //Inside another class
   ...
   public void AddEnhancedControl ( Control ctrl )
   {
      ControlWrapper wrapper = new ControlWrapper(ctrl);
      ...
      if (wrapper != null)
         wrapper.DoWork();
   }
   
   

   It is important to understand the difference between ArgumentNullException and NullReferenceException. An ArgumentNullException is thrown when an argument to a method/property is null. A NullReferenceException is thrown when you attempt to use a null reference.

   When you get a NullReferenceException you are using an object somewhere that is null. In the case of the code given it is unlikely that the wrapper variable is null because new will throw an exception rather than return null. However the wrapper class does not check for null either in the constructor (where it probably should) nor when it uses the field inside the method. This is the probable cause of the exception.

   Notice that the if statement has no real effect here. Remember that an object can be non-null and still generate a NullReferenceException if it has any fields that are null.

6. You have a WinForms application where you want to trap all unhandled exceptions and generate a nice message to the user while logging the important information for later diagnostics. You put a try-catch around all your code in your Main routine but your catch code is never called. What is going on?  Answer

   This question comes up a lot in the forums. The first thing you need to ask yourself is if it is even necessary. The default behavior for WinForms apps is to generate a nice exception dialog. Furthermore Windows will generate a crash dump that can then be loaded into the debugger for diagnostic purposes. You are generally not gaining much by doing this yourself but we'll suppose for the moment it is necessary. The following program will help demonstrate the concepts.

   public class Form1 : Form
   {
      [STAThread]
      static void Main ()
      {
         Application.EnableVisualStyles();
         Application.SetCompatibleTextRenderingDefault(false);
   
         //Step1: Handle UI exceptions
         Application.ThreadException += OnUIThreadException;
   
         //Step2: Handle non-UI exceptions
         AppDomain.CurrentDomain.UnhandledException += OnNonUIThreadException;
   
         //Step3: Handle all UI exceptions
         Application.SetUnhandledExceptionMode(UnhandledExceptionMode.CatchException);
   
         try
         {
             Application.Run(new Form1());
         } catch (Exception e)
         {
            MessageBox.Show(e.Message, "In Main");
         };
      }
   
      public Form1 ()
      {
         Button btnThrowUI = new Button();
         Button btnThrowNonUI = new Button();
   
         btnThrowUI.Location = new System.Drawing.Point(89, 67);
         btnThrowUI.Name = "btnThrowUI";
         btnThrowUI.Size = new System.Drawing.Size(85, 23);
         btnThrowUI.TabIndex = 0;
         btnThrowUI.Text = "Throw UI";
         btnThrowUI.UseVisualStyleBackColor = true;
         btnThrowUI.Click += new System.EventHandler(this.ThrowUI_Click);
   
         btnThrowNonUI.Location = new System.Drawing.Point(89, 119);
         btnThrowNonUI.Name = "btnThrowNonUI";
         btnThrowNonUI.Size = new System.Drawing.Size(85, 23);
         btnThrowNonUI.TabIndex = 1;
         btnThrowNonUI.Text = "Throw Non-UI";
         btnThrowNonUI.UseVisualStyleBackColor = true;
         btnThrowNonUI.Click += new System.EventHandler(this.ThrowNonUI_Click);
   
         ClientSize = new System.Drawing.Size(284, 264);
         Controls.Add(btnThrowUI);
         Controls.Add(btnThrowNonUI);
         Name = "Form1";
         Text = "Form1";
      }
      private void ThrowUI_Click ( object sender, EventArgs e )
      {
         throw new InvalidOperationException("UI thread");
      }
      private void ThrowNonUI_Click ( object sender, EventArgs e )
      {
         Thread thread = new Thread(DoWork);
         thread.Start();
      }
      private void DoWork ()
      { throw new InvalidOperationException("Non-UI thread");
      }
   
      //Step1
      private static void OnUIThreadException ( object sender, ThreadExceptionEventArgs e )
      {
         MessageBox.Show(e.Exception.Message, "Application.ThreadException");
      }
   
      //Step2
      private static void OnNonUIThreadException ( object sender, UnhandledExceptionEventArgs e )
      {
         Exception ex = e.ExceptionObject as Exception;
         MessageBox.Show((ex != null) ? ex.Message : "Unknown exception", "AppDomain.UnhandledException");
      }
   }

   WinForms have an implicit try-catch wrapped around the call to Application.Run. Therefore any catch block you wrap around this method will not be called. Instead you need to hook into the existing infrastructure. This is a multistep process: handle UI exceptions, handle non-UI exceptions, force processing of all exceptions.

   Handling UI exceptions involves working with Application as it is the class that is ultimately handling UI exceptions and displaying the exception dialog. To handle UI thread exceptions subscribe and handle the Application.ThreadException event. This event is raised when an unhandled exception on the UI thread occurs. Refer to the Step1 comments in the code.

   The second step is to handle non-UI exceptions. Application does not deal with non-UI exceptions so you have to go back to the appdomain. Handle AppDomain.UnhandledException to handle exceptions on non-UI threads. Refer to Step2 in the code.

   The final step is to tell Application to handle all unhandled UI exceptions. This ensures that all the exceptions go to our handler. It requires calling the Application.SetUnhandledExceptionMode method with the UnhandledExceptionMode.CatchException option. See step 3

   A final warning. The above discussion is only about reacting to exceptions. In several situations, irrelevant of what you do, the application is still going to terminate. Therefore you should generally not try to recover from the exception or reference anything that might throw another exception.