Re: Exception handling?

Not knowing what are all the possible "error" conditions for the .NET
library, I got into a practice of wrapping try catch around much of the
code blocks but also working in the Try Catch Finally logic where
necessary to return negative or positive results. A good last example was
adding a search logic using the Regular Expression .NET library.

public bool SearchForums(string sPattern)
{
  try
  {

    Regex rgx = new Regex(sPattern, RegexOptions.IgnoreCase);
    foreach (var forum in ForumsList)
    {
      MatchCollection matches = rgx.Matches(forum.Description);
      if (matches.Count > 0)
      {
          /// got something
      }
    }
    return true;
  }
  catch (Exception ex)
  {
    MessageBox.Show("Regular Expression Error: " + ex.Message);
  }
  return false
}

This turned out to be nice because for illegal sPattern syntax the class
throws an exception with detail description of the syntax error. I am glad
it did this and not me and it also became a "help" for the the user and
not something we have to documentation.

Today, I believe that exception trapping is a vital necessary design
especially for environments .NET. There is still the issue of
programmings not grasp everything, but the throw exceptions are "better"
or rather design with the intent that developers will use them to provide
non-critical feedback.

You can get in trouble though when you don't understand the errors. This
last example is a good illustration where an explicit exception catch was
used but was a critical abort failure when implemented in a different way.

The Windows Live ID SDK has an example implementation where the main
program.cs has a catch for specific exception handler for

         System.IO.FileNotFoundException

like so:

using System;
using System.Collections.Generic;
using System.Windows.Forms;
using Microsoft.Win32;

namespace WindowsLiveIDClientSample
{
    static class Program
    {
        /// <summary>
        /// The main entry point for the application.
        /// </summary>
        [STAThread]
        static void Main()
        {
            Application.EnableVisualStyles();
            Application.SetCompatibleTextRenderingDefault(false);

            try
            {
                Application.Run(new MainWindow());
            }
            //System requirement detection.
            catch (System.IO.FileNotFoundException fnfex)
            {
                //Checking for the absence of the Windows Live Sign-In
Assistant DLL.
                if (fnfex.Message.Contains("WindowsLive.ID.Client"))
                {
                    MessageBox.Show("Please install the Windows Live ID
For Client Applications SDK.");
                }
                else
                {
                    MessageBox.Show(fnfex.Message);
                }
            }
            finally
            {
                Application.Exit();
            }
        }
    }
}

Well, if you isolate this LiveID class into your own library and the
LiveID component was not already installed, then you get an exception that
is not System.IO.FileNotFoundException.

I learn the hard way that this exception was only correct when the LiveID
assembly was bound to the EXE and not a helper DLL.

The solution was simple, again, not knowing what are the possible specific
exceptions, I used catch all instead and checked for the "LiveID" string
in the exception message.

The sad fact is this - its here. It is what it is, libraries are done
mostly one way now and developers have no choice but get use to it and
learn how to work with it.