Best Practices - Exception Handling

2008-05-29T00:18:00.004+05:30

The developer develops the code by sitting day and night but at the end if the code fails because of some exception which he/she failed to handle during the development then everything goes for a toss. I thought of sharing the best practices on Exception Handling which can help you all to write good code.

Only throw exceptions in exceptional situations

Do not throw exceptions in situations that are normal or expected (e.g. end-of-file). Use return values or status enumerations instead. In general, try to design classes that do not throw exceptions in the normal flow of control. However, do throw exceptions that a user is not allowed to catch when a situation occurs that may indicate a design error in the way your class is used.

Do not throw exceptions from inside destructors

When you call an exception from inside a destructor, the CLR will stop executing the destructor, and pass the exception to the base class destructor (if any). If there is no base class, then the destructor is discarded.

Re-throwing of exceptions

Exceptions should be re-thrown in one of two situations:

You want to specialize the exception and possibly provide further information.
You need to perform some error correction due to the exception but are then also required to allow the exception to propagate back to the caller

To specialize the exception, you must set the innerException property of the new exception you are throwing like so: -

try
{
//code…
}
catch(SOAPException e)
{
Throw new RemapUIException("Unable to communicate with SSF", e)
}

This will ensure the stack trace of where the original exception occurred is preserved. To perform error correction code and then propagate the exception higher up the call stack, issue the throw statement on its own. Never re-throw the same exception as this will create a new exception stack trace and destroy the original stack info:-

WRONG:-

try
{
//code…
}
catch([ExceptionType] e)
{
//perform catch and error handling code..
throw e;
}

CORRECT:-

try
{
//code…
}
catch([ExceptionType] e)
{
//perform catch and error handling code..
throw;
}

List the explicit exceptions a method or property can throw.

Describe the recoverable exceptions using the <exception> tag. Explicit exceptions are the ones that a method or property explicitly throws from its implementation and which users are allowed to catch. Exceptions thrown by .NET framework classes and methods used by this implementation do not have to be listed here.

Always log that an exception is thrown

Logging ensures that if the caller catches your exception and discards it, traces of this exception can be recovered at a later stage.

Allow callers to prevent exceptions by providing a method or property that returns the objects state

For example, consider a communication layer that will throw an InvalidOperationException when an attempt is made to call Send() when no connection is available. To allow preventing such a situation, provide a property such as Connected to allow the caller to determine if a connection is available before attempting an operation.

Use standard exceptions

The .NET framework already provides a set of common exceptions. The table below summarizes the most common exceptions that are available for applications.

Exception	Condition
IndexOutOfRangeException	Indexing an array or indexable collection outside its valid range.
InvalidOperationException	An action is performed which is not valid considering the object's current state.
NotSupportedException	An action is performed which is may be valid in the future, but is not supported.
ArgumentException	An incorrect argument is supplied.
ArgumentNullException	An null reference is supplied as a method's parameter that does not allow null.
ArgumentOutOfRangeException	An argument is not within the required range.

Throw informational exceptions

When you instantiate a new exception, set its Message property to a descriptive message that will help the caller to diagnose the problem. For example, if an argument was incorrect, indicate which argument was the cause of the problem. Also mention the name (if available) of the object involved.

Also, if you design a new exception class, note that it is possible to add custom properties that can provide additional details to the caller.

Throw the most specific exception possible

Do not throw a generic exception if a more specific one is available.

Only catch the exceptions explicitly mentioned in the documentation

Moreover, do not catch the base class Exception or ApplicationException or System.SystemException. Exceptions of those classes generally mean that a non-recoverable problem has occurred.

Exception:

On system-level or in a thread-routine, it is allowed to catch the Exception class directly, but only when approval by the Senior Designer has been obtained.

Derive custom exceptions from ApplicationException

All exceptions derived from SystemException are reserved for usage by the CLR only.

Provide common constructors for custom exceptions

It is advised to provide the three common constructors that all standard exceptions provide as well.

These include:

XxxException()
XxxException(string message)
XxxException(string message, Exception innerException)

Avoid side-effects when throwing recoverable exceptions

When you throw a recoverable exception, make sure that the object involved stays in a usable and predictable state. With usable it is meant that the caller can catch the exception, take any necessary actions, and continue to use the object again. With predictable is meant that the caller can make logical assumptions on the state of the object.

For instance, if during the process of adding a new item to a list, an exception is raised, then the caller may safely assume that the item has not been added, and another attempt to re-add it is possible.

Do not throw an exception from inside an exception constructor

Throwing an exception from inside an exception's constructor will stop the construction of the exception being built, and hence, preventing the exception from getting thrown. The other exception is thrown, but this can be confusing to the user of the class or method concerned.

Custom Exceptions

To avoid ambiguity, all custom exceptions should descend from a new base exception and create a new set of exception hierarchies specific to the application or Framework. This will then allow all custom application/framework exceptions to be caught by one catch if required (and totally removes the requirement of catching ApplicationException in such situations).

Performing the above provides the following advantages:-

No custom exceptions directly fall under ApplicationException. This is important as certain reflection exceptions 'appear' under the ApplicationException class tree so these could inadvertently be caught if ApplicationException is used to 'catch' any 'application error' that has occurred.
Provides an easy mechanism to separate out different custom exception hierarchies, based on each application/framework.
Provides an easy way to catch 'related' exceptions without having to determine the except type.

Article courtesy: Ashok Kumara Purlehalli from Microsoft

Some other best practices articles:

Technorati Tags: .net,best practices,microsoft,programming

Cloning an Oracle Database in 10 steps

2007-05-30T17:38:00.001+05:30

Here the author explains how to clone an Oracle database in 10 simple steps. 10 steps for cloning a database

Technorati tags: oracle, cloning

VBScript Editing in Visual Studio

2005-11-29T01:23:00.000+05:30

After much frustration with Notepad I have worked out this solution. It provides color coding of VBScript commands but not IntelliSense for the Wscript object. (need the equivalent of references in VB)When you open a .vbs file in Visual InterDev it is treated as a text file. To force VI to use the HTML editor (used for ASP and client side code color editing) you must make some changes to the registry. First delete the value 'vbs' from this key (if it exists)

HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\6.0\Editors{8B382828-6202-11d1-8870-0000F87579D2}\Extensions

and add a new DWORD value called 'vbs' with hex value 28 to this key

HKEY_LOCAL_MACHINE\Software\Microsoft\VisualStudio\6.0\Editors{C76D83F8-A489-11D0-8195-00A0C91BBEE3}\Extensions

Now to create an option for creating a new vbs file in the 'File', 'New File' menu, edit the file

{$Install_Drive}\Program Files\Microsoft Visual Studio\VIntDev98\Templates\NewFileItems\NewFileItems.vsdir

and add a new line at the end of the file (it is a long line that may wrap over several lines)

New vbs File.vbs|{164B10B9-B200-11D0-8C61-00A0C91E29D5}|VBS File|60|Create a new vbs file and add open it in the editor|c:\WINDOWS\Wscript.exe|3| |VBS File

Confirm the path to Wscript.exe which is used to get the icon to display in the dialog box. You MUST add an additional CRLF at the end of this file otherwise VI will hang (there is one blank line for each entry). Now create a file in the same directory called New vbs File.vbs with the following lines...

'<% This line will turn on the color coding' add any standard commands you want to make this a template vbs fileSet WshShell = WScript.CreateObject("WScript.Shell")Set oFS = WScript.CreateObject(Scripting.FileSystemObject)

Sort randomly

2005-04-27T23:55:00.000+05:30

To sort radomly every time you run the query, use this method,

SELECT columnname1, columnname2 FROM YOURTABLE ORDER BY NEWID()

Days of the month using SQL

2005-04-27T20:29:00.000+05:30

To find the days in a month using SQL, use the following method. Here TSQL syntax is used for example.

--------------------
DECLARE @Date datetime
SET @Date = '2000/02/1'
SELECT DATEADD(dd,-(DATEPART(dw, @Date) - 1),@Date) AS 'First day of the week'
SELECT DATEADD(dd,-(DATEPART(dw, @Date) - 7),@Date) AS 'Last day of the week'
SELECT DAY(DATEADD(d, -DAY(DATEADD(m,1,@Date)),DATEADD(m,1,@Date))) AS 'Last day of the month'
--------------------

for more sql tricks goto.. Extremeexperts