There are four main types of errors that you will encounter at some point in time.

Four main types of errors:
1. Configuration errors - Errors that are caused by problems that are found in the web.config or the machine.config files.
2. Parser errors - The cause of this type of error is incorrect syntax in an ASP.Net page.
3. Compilation errors - This error is fired via the compiler.
4. Runtime errors - This error is fired at page execution.

The term you will grow to love is simply called exception handling and what this means is anything that happens in your application that is unexpected or undesired.

Properties of the exception class:
1. StackTrace - Gets a string representation of the frames on the call stack at the time the current exception was thrown.
2. InnerException - Gets the exception instance that caused the current exception.
3. Message - Gets a message that describes the current exception.
4. HelpLink - Gets or sets a link to the help file associated with this exception.
5. Source - Gets or sets the name of the application or the object that causes the error.
6. TargetSite - Gets the method that throws the current exception.
7. HResult - Gets or sets HRESULT, a coded numerical value that is assigned to a specific exception.

Be sure to examine the exception class.

Quick Example Catch
Whenever you execute a statement that has the potential to fail; you will want to wrap the statement in a try…catch block. This way you can handle any runtime errors that may result from the statement.

To start off with catches, you have use try....catch….finally syntax. It looks like this:

try 
{   
    // some part of the coding whereupon it might fail at runtime 
}
catch (Exception e) 
{   
    //  block of code that does error handling 
}
finally 
{   
    // coding that will run no matter what happens before this point 
}

Now that you have the general knowledge of the types of errors that you may encounter and a basic example of the try...catch... finally syntax it is time to move on to a more in depth discussion.

The first two items we are going to discuss is error handling using the web.config and the global.asax files.

Custom errors are beneficial in many aspects. You can either hide errors or provide a more detailed error messages. To utilize custom errors you must use the customErrors section within your web.config file.

Example:
<configuration>
<system.web>
<customErrors mode="on" defaultRedirect="MyApplicationError.aspx">
<error statusCode = "404" redirect="My404.aspx">
' Feel free to add other error types…
</customErrors>
</system.web>
</configuration>

If you prefer there is another option that you may use on a page to page basis.

Example:
<%@ Page ErrorPage=" MyApplicationError.aspx" %>

As indicated the global.asax can also be used to assist you in error handling. One beneficial item you could do here is to establish a method that that will send out an email to an individual or individuals when an error occurs. This way you can be proactive and tackle the issue when it arises.

At this point you time you should understand the basics of using of the try...catch...finally blocks for wrapping statements that could fail and the use of the web.config and global.asax files to assist in error handling.

The System.Diagnostics namespace provides the foundation for troubleshooting your applications - debugging, event logging, performance monitoring, and interacting with system processes. Here we are concerned about the EventLog class and how we will use it.

For the purposes of this example, we are just going to log any application errors. We are going to be logging these type of entries to the Application Log on the server itself. This is where most applications log their errors, warnings and information.

Example Class:

using System;
using System.Diagnostics;
using System.IO;


namespace System.Diagnostics
{
 /// <summary>
 /// Summary description for article06012004.
 /// </summary>
 public class article06012004
 {


  static void Main(string[] args)
  {
   MoveDirectory();
  }


  public static void MoveDirectory()
  {
   string directoryPathToMove = @"c:\MyDirectory";
   string directoryPathMoveLocation = @"c:\MyDirectory1";


   try
   {
    Directory.Move(directoryPathToMove, directoryPathMoveLocation);
   }
   catch(Exception err)
   {
    logError(err.ToString(),"ASPAllianceArticle06012004");
   }


  }


  public static void logError(string strError, string strSource) 
  {
   System.Diagnostics.EventLog myEventLog = new System.Diagnostics.EventLog();
   
   myEventLog.Source = strSource;
   myEventLog.WriteEntry (strError, System.Diagnostics.EventLogEntryType.Error);
   myEventLog.Close(); 
  }
 }
 
}

If an Exception is in fact thrown you can then see this error in your event log.

By using this approach you can code for as much or as little details as your requirements ask for. This way you will have the necessary information to fix any problems that may arise.