Re: Exception handling?

Today Joe, IMV, its a more a matter of documentation. The overhead is
somewhat less important in this "Bulky Code" world, attempting to
optimize for size or speed is of less important or negligible in a
already heavy handed OS load environment. Developing applications in
a p-code environments are par for the course today.

I think part of the problem for developers is a separation of whats
critical vs whats natural and/or expected.

Often the complexity (possibly due to lack or complex documentation)
promotes using a single catch all (more below).

When the components are "better understood" sometimes being explicit
in exception trapping is useful, other times its not.

Another problem is that constructors do not lend itself for functional
programming and exceptions are required, if necessary for the class logic.

And of course, as the generation continues, library designers are more
oops and event programming oriented and thus use less functional
programming (FP) techniques and sometimes too much oops orientations
for the simplest of constructs. As you know, in the early days, good
library designers (by necessity for the better brand) use to provide
frameworks for different types of OOPS vs FP programming audience - an
expensive upkeep in the long run - something has to give, and the
trend is and has been OOPs, FP mentions gets less attention. But then
again, the irony is that you see the same people going back to FP
technique or adding it, ALA F#.

A good example is my recent experiences with my real first .NET
project, wcLEX (Wildcat! Live Exchange). I am using this project to
(re)learn all the .NET particulars and "How To's" for the more
expensive product migration move coming.

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.

In short, 10-15 years ago, my belief in using exception was a crutch
for not understanding code but also sometimes you had no choice before
the OOPs class did not lend itself to controlled FP methods. But I
thought it promoted bad coding overall.

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.

My take on it.

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.

--
HLS

Joseph M. Newcomer wrote: