In this tutorial we will go over error handling within code blocks that can make a program more robust and less susceptible to crashing because the application will handle these errors.

Exception Handling: Best Practices C#

In this tutorial we will go over error handling within code blocks that can make a program more robust and less susceptible to crashing because the application will handle these errors.

This tutorial will go over the best practices for Handling Exceptions in an ASP.NET 3.5 Web Application C#.

If you're looking for a really good web host, try Server Intellect - we found the setup procedure and control panel, very easy to adapt to and their IT team is awesome!

Here are a few questions and answers to take into consideration when handling exceptions:

Q: When do I set up a try/catch block?

A: programmatically check for conditions that you feel might occur without using exception handling. Otherwise, use exception handling to catch an error.

Here is an example that uses an if statement to check whether a conn() is closed or not. Use this method instead of throwing an exception if the conn() is not closed.

The method that you determine depends on how much you expect the event to arise. Keep this in mind:

If the event is absolutely exceptional and is an error, such as an unexpected-end-of-file, then using exception handling is better because less code is needed to execute. However, if the event happens often, then using programmatic methods to check for errors is definitely better.

Q: Should I use try/finally blocks around code that can potentially generate an exception and centralize my catch statements in one location?

A: I would, use the try statement to generate the exception, the finally statement closes or de-allocates resources, and the catch statement handles the exception from a centralized location.

Q: How do I order exceptions in catch blocks?

A: Good practice is to always order exceptions in catch blocks from the most to least specific. This way it handles the specific exception before it is passed to a more general catch block.

Q: Should I design classes so that an exceptions are never thrown in normal use?

A: A good example of this may be a FileStream class. It determines another way rather than an exception to see if the end-of-file has been reached. This could escape the exception that is thrown if you read past the file. Here is an example of how to read to the end of the file:

The first if statement is completely optional because its unlikely that the stream would ever be null. The fileToRead sets the stream position to the beginning of the file. Then the for loop reads each byte to the end of the file.

We migrated our web sites to Server Intellect over one weekend and the setup was so smooth that we were up and running right away. They assisted us with everything we needed to do for all of our applications. With Server Intellect's help, we were able to avoid any headaches!

Keep in Mind these Good Practices

• Always end exception classes with the word “Exception”
  i.e.  Public class MyFileNotFoundException: Exception {}
• Use predefined exception types. Only introduce a new exception class to allow a programmer to take different action in code based on the exception class.
• Most custom exceptions should be derived from the exception class.
• Always include a localized description string in each and every exception. This way when the user sees an error message, it will be derived from the description string of the exception that was thrown, rather than from the exception class.
• Do not forget that each sentence in a description string of an exception should end in a period. Use correct punctuality and grammar within these error messages.
• Return a null for extreme common error cases. A good example is to return a null if the file is not found, but throw an exception if the file is blocked.