Exception Handling in .Net

[Bruno007]

I was recently asked about how they should deal with exception handling for a large application. I was pleased that the person was made aware that there is an issue that can be left to chance and must take certain issues into account. Basically, your question was about how to capture a unified all exceptions thrown in your application, after some research, came to know of Application.ThreadException, an event that you can put a handle and then take the necessary actions. However, I personally do not recommend this solution. Why?

1. Notification of the exception is too late: when receiving the notification, the application can not respond to the exception.
2. The application will terminate abruptly if the exception occurs in the main thread or other thread which is initiated by unmanaged code (the main application thread is obviously executed by Windows - unmanaged)
3. We have no access to any valuable information about the error, but the exception itself. Not be closing connections to databases, transaction rollback or anything useful.

So my advice is never based on exception handling and AppDomain.UnhandledException Application.ThreadException events. They should be used and there are safety nets as the acrobats, its function is to make a record of the exception in a log mechanism for any future examination. So you must be the peel and handle each exception in place and act accordingly.

[Bruno007]

Put code between try, catch it runs very slow. Resource intensive. So just handle exceptions when they really needed. When is that? The exceptions are built to handle conditions that can not be controlled with the application logic. For example that drops the connection to the server, or the disk is full, or the hardware failed ... Before throwing exceptions for everything, let's look is really necessary. Avoid putting too much code in the try, try to deal only with code that can actually fail. For example is preferable:

if (con.State! = ConectionState.Closed)
 {      
    con.Close (); 
 } 

to: 
  try
 {
         con.Close (); 
 } 
 catch (InvalidOperationException exp)
 {
      Console.WriteLine (exp.GetType (). FullName);
      Console.WriteLine (exp.Message);
 }

Do not issue Exception (). Or is that it gives much information? The framework. Net has a number of exceptions that allow us to control arguments and invalid operations, timeouts, connections, overflows, etc. Let us use these exceptions really tell us what had happened.

[Bruno007]

Use try / finally. Remember that the instructions in the Finally always executed regardless of whether or not the exception occurred. This is very useful to free resources, close connections. Always use a catch for each type of exception that can generate and sort them from most specific to least specific. This helps to fully identify the error that is generated and not end up with exceptions such as: "Object reference not set to a instance of an Object". When you create custom exceptions of the application, be sure to distribute the Assembly to a shared location for all possible domains that have to do with them. Depending on how the work exceptions mechanism is very important whenever we think Exceptions own, provide them with at least three builders exceptions basic. It is always advisable to use exceptions. Net The only custom settings will be related program. Always thought that custom exceptions should inherit from ApplicationException, but in practice has shown that there is significant value added and also lose some performance. So it's always better to inherit from Exception. Use grammatically correct messages. Exceptions may include properties. These properties can be accessed programmatically to take action. Include extra information relevant to these properties when it is useful.

[Bruno007]

Instead of returning null, throw exception in most cases. This avoids problems that are sometimes difficult to detect. Avoid also return error codes. These are just a few recommendations when handling exceptions. There are many more that are learned with the passage of lines of code. Finally, it seems important to mention that as there is an Application Block in Patterns and Practices for handling exceptions. Including them in our applications already guaranteed several good practices, yes, just using it which is explained in the guidelines.

[Ananika]

I have a doubt with the Exception Handling Application Block Hands-On Labs for Enterprise Library, to be more accurate if you try to run the Final Laboratory exercise 1 and 2 throws errors as if the lab does not work, in the case of period 1 when attempts to throw the exception using the Throw class fails and can not find the event handler, and exercise as 2 passes only this time with security policies, let me know where this error since it is assumed the project in the final version should work without problems. I am running the project with VST2010 Framework 3.5 and 4.0. One thing I've seen that is very common to use error codes, why not recommended? What would be the appropriate strategy?

[Bruno007]

When you boot error codes automatically embarks on the task of creating the mechanisms to administer these codes. New codes for new exceptions, the tables show the clients of the application, synchronize the codes when they change ... and all the problems this may cause. For example a customer has the v1.0 of the error code table, and the access codes needed to make v2.0 wing, generating therefore an exception of exceptions ... The error codes were a great alternative in environments where there were exceptions (VB, C, T-SQL).

But in a managed language like C # or VBNet, the same framework provides a set of exceptions that represent exactly what happened and can also enrich adding data inherent in the exception occurred, not to mention that for example also have StackTrace information so that customers can always find out exactly what had happened without resorting to tables of equivalence that may not have or are date.