WCF Fault Exception

Martin had an obscure problem with WCF on our Fitspace / Fitness First Widget.

This article describes a similar issue Obscure WCF Exception mislaid blame

Unhandled Exceptions in VS2008

In our solution we have two basic projects: Client and Server, communicating via WCF.

When the Server components throw an exception the Server's WCF layer catches it, wraps it up as a FaultException and rethrows for the Client to catch.

Even though the exception is handled the debugger signals an unhandled exception when running the Server though VS2008.

From the Debug | Exceptions menu option I've turned the exception handling off for that one specific type: System.ServiceModel.FaultException`1

It would appear that disabling this exception affects only the Server project.

Speed of Exceptions

I wanted to check for duplicates as entries were being added to my Dictionary collection. I wasn't sure whether to use ContainsKey and check each and every time an item is added or simply sweep up after the Add method throws an Exception.

In reality the best solution will depend on the likely hit rate of duplicates but I thought I'd write the following code to test the speed differential when the hit rate is 100%.

Using ContainsKey

private void Button_Click(object sender, RoutedEventArgs e)
{
   DateTime start = DateTime.Now;
   for (int i = 0; i <= 1000; i++)
   {
      if (dummy.ContainsKey("Sunday"))
      {
         dummy["Sunday"]++;
      }
   }
   DateTime end = DateTime.Now;
   MessageBox.Show(end.Subtract(start).TotalMilliseconds.ToString());
}

Using Exceptions

private void Button_Click_1(object sender, RoutedEventArgs e)
{
   DateTime start = DateTime.Now;
   for (int i = 0; i <= 1000; i++)
   {
      try
      {
         dummy.Add("Sunday", 7);
      }
      catch
      {
         dummy["Sunday"]++;
      }
   }
   DateTime end = DateTime.Now;
   MessageBox.Show(end.Subtract(start).TotalMilliseconds.ToString());
}

Results
Using ContainsKey: 2 milliseconds
Using Exceptions: 5338 milliseconds

The ContainsKey adds about 0.04 milliseconds for the 1000 iterations - the rest is the down to the increment of the Dictionary int value.

Page / Window Constructor

According to Rockford Lhotka:

"Putting code in a Page/Window constructor is bad. Yes, I know it is the “C# way”, but it is bad. The “VB way” of putting code in the Loaded event handler is better.

Why?

Because any exceptions thrown in the constructor prevent the page/window from loading at all, and you have to catch those exceptions in the code that is creating the page/window. In many navigation scenarios you can’t catch them, so the user gets an ugly WPF exception dialog.

However, if you do all your init work in the Loaded event handler, the page/window instance already exists. Navigation has already happened, so the “calling code” is no longer responsible for your page/window going haywire. Instead, you can actually handle the exception and show a nice dialog, explaining to the user what happened, and you can (if desired) navigate somewhere else or whatever."

Exceptions in Converters

Karl Shifflett says:

It is vital that your value converters not throw or be allowed to bubble exceptions because the data binding pipeline does not catch, swallow or handle these exceptions. Instead your users will get those messy exceptions messages because there is no method to catch and handle exceptions in XAML markup. Ensure that if your converter fails that you gracefully handle this conversion or convert back operation.