Best Practice to Handle Exceptions

Modern programming languages come with try/catch/finally blocks and many times an Exception Hierarchy of classes is provided also.
Exceptions are a powerful tool that can be used to handle both system and user errors.
When exceptions are thrown in some part of the code, the system keeps popping ( removing the head ) of the stack until it finds a catch statement that can handle that exception type.
One common way to capture exceptions is to write several catches from the most specific to the most generic exception class until you can capture the exception type appropriately according to its type.
Check code below:

try
{
  // code block
}
catch ( SpecialSystemException e)
{
  // code to handle SpecialSystemException  
}
catch ( SystemException e)
{
  // code to handle SystemException
}
catch ( Exception e)
{
  // code to handle Exception
}
finally
{
  // finishes code block
}

However in many cases it is desired to treat each exception same way according to its type in the entire system. In this case the code template shown above has some disadvantages:

• Programmers must write more code to implement try/catch/finally code blocks to due the several "catch" statements for each exception type that is intended to treat
• Code to treat exception classes are replicated in the software code
  
• And finally if it demands more work and it is repeated than it is error prone

In order to solve this problem a better approach is to create a separate centralized class to treat all exceptions thrown from the system internally. Like the .NET pseudo-code example below:

public class ExceptionHandler
{
  public static void Handler(Exception exception)
  {
    if (exception.GetType() == typeof(SpecialSystemException))
    {
      // Code that deals with SpecialSystemException 
    }   
    else if (exception.GetType() == typeof(SystemException))
    { 
      // Code that deals with SystemException
    }
  else if (exeception.GetType() == typeof(Exception))
  {
      // Code that deals with Exception
    }
}

Replacing the code of the first example:

try
{
  // code block
}
catch ( Exception e)
{
  // Exceptions are now treated internally by the method below
  ExceptionHandler.Handler(exception);
}

Choosing the Right Primary Keys

One of the most common data modeling is the use of composite keys and natural keys as primary keys to identify tables in the database.
Composite-key tables use more than one key to identify a row while natural keys use domain information to identify a row such as Social Security Number to identify a Person. In most cases a composite-key is actually a composite-natural-key.

However these tecniques are not consider good practices to choose the table primary keys due to the following factors:

• Business Rules change over time but primary keys don't
  
• Business rules are dynamic but primary keys are static until you update the database model what can cost a lot time and effort if not impossible. For example if you identify a Client with a Social Security number you may not be able to identify a foreign Person if needed or maybe the government can decide to use the same Social Security Number for more than one person. This lack of capacity to change the database model can reduce significantly the agility of an organization to adapt its business model to new kind of reality what reduces its capacity to compete with other organizations.

Figure 1 - Table identified by a natural key

• Composite Keys require more work
• It is necessary to write longer SQL queries since you have to use all the primary keys to join this table to another one.

select cli.name, pd.description, sa.date, sa.quantity
from Client cli
inner join Sales sa on
( cli.socialSecurityNumber = sa.socialSecurityNumber )
inner join Product pd on
( sa.idProductType = pd.idProductType and
sa.vendorRegistration = pd.vendorRegistration )
where sa.date >= '2007-12-01'

• Make the Database model less readable
• Composite keys spread to other tables as a foreign key and are added to other foreign composite-key columns. In some cases where composite-keys are widely used there are much more composite-key columns in a table than useful information.

Figure 2 - Only date and quantity are Sales columns

the rest are inherited primakey keys from other tables

In the other hand one of the stronger arguments in favor of composite and natural-keys is that they provide a safer way to restrict data integrity avoiding certain columns in a table to repeat while with a single primary key can not garantee this.
But many people forget that this data integrity can be done in single-primary tables too by using alternate keys. With alternate keys you can choose a group of columns in a table make them unique just like a composite-key would do it.

In order to present this idea in more details below there are two examples, one with the traditional composite-key and natural keys aproach and the other with the proposed idea of using single primaty keys ( non-natural keys ) and alternate keys.

Figure 3- Data model example that makes use of natural-keys

Figure 4 - Data model example with single primary keys and alternate keys