Exception Handling Guidelines

Forums and Minerals, the new Internet tools

Image via Wikipedia

Follow class naming conventions, but add Exception to the end of the name.
Some rules listed below are to be followed in Exceptions blocks or classes:

  1. Never do a “catch” exception and do nothing. If you hide an exception, you will never know if the exception happened or not.
  2. In case of exceptions, give a friendly message to the user, but log the actual error with all possible details about the error, including the time it occurred, method and class name etc.
  3. Always catch only the specific exception, not generic exception as well as system exceptions.
  4. You can have an application level (thread level) error handler where you can handle all general exceptions. In case of an ‘unexpected general error’, this error handler should catch the exception and should log the error in addition to
    giving a friendly message to the user before closing the application, or allowing the user to ‘ignore and proceed’.
  5. Do not write try-catch in all your methods. Use it only if there is a possibility that a specific exception may occur. For example, if you are writing into a file, handle only FileIOException.
  6. Do not write very large try-catch blocks. If required, write separate try-catch for each task you perform and enclose only the specific piece of code inside the try-catch. This will help you find which piece of code generated the exception and you can give specific error message to the user.
  7. You may write your own custom exception classes, if required in your application. Do not derive your custom exceptions from the base class SystemException. Instead, inherit from ApplicationException.
  8. To guarantee resources are cleaned up when an exception occurs, use a try/finally block. Close the resources in the finally clause. Using a try/finally block ensures that resources are disposed even if an exception occurs.
  9. Error messages should help the user to solve the problem. Never give error messages like “Error in Application”, “There is an error” etc. Instead give specific messages like “Failed to update database. Make sure the login id and password are correct.”
  10. When displaying error messages, in addition to telling what is wrong, the message should also tell what the user should do to solve the problem. Instead of message like “Failed to update database.” suggest what should the user do: “Failed to update database. Make sure the login id and password are correct.”
  11. Show short and friendly message to the user. But log the actual error with all possible information. This will help a lot in diagnosing problems.
  12. Define a global error handler in Global.asax to catch any exceptions that are not handled in code. You should log all exceptions in the event log to record them for tracking and later analysis.

Listen for Removable Device events

Handling device events in the .net framework is not an easy task and is really cumbersome for many developers. Application developers often need to listen for some hardware events, such as adding or removing a USB Flash memory or disconnecting an external hard disk and do some application logic based on that event. For example, consider an application that runs on a server and the administrator wants to keep track of what Plug & Play devices are being attached to this server on daily basis. We also want to track the name of the attached device, its size and probably the files that are being transfered from and to the device.

It seems frustrating and hard to implement using the ordinary .net libraries available. So we will resort to using WMI to query the operating system for this information and create or own RemovableDevice wrapper.

We need to add a reference to System.Management to get the WMI APIs. The key behind this whole feature lies in the ManagementEventWatcher class by firing a query against Win32_VolumeChangeEvent, which is a win32 object that stores information about volumes and storage devices attached to the machine, to listen for Hardware events, then handle the MediaConnectWatcher.EventArrived event to distinguish the event types and fire our custom events based on those. Below is the full implementation of our RemovableDevice wrapper:

Imports System.Management

Public Class RemovableDevice

    Public Enum VolumeEventType As UInteger
        ConfigurationChange = 1
        DeviceArrival = 2
        DeviceRemoval = 3
        Docking = 4
        Any = 5
    End Enum

    Private Shared WithEvents MediaConnectWatcher As System.Management.ManagementEventWatcher
    Public Shared Event OnAnyChange(ByVal EventType As VolumeEventType, ByVal DriveName As String, ByVal TimeCreated As Date)
    Public Shared Event OnConfigurationChange(ByVal DriveName As String, ByVal TimeCreated As Date)
    Public Shared Event OnArrival(ByVal DriveName As String, ByVal TimeCreated As Date)
    Public Shared Event OnRemoval(ByVal DriveName As String, ByVal TimeCreated As Date)
    Public Shared Event OnDock(ByVal DriveName As String, ByVal TimeCreated As Date)
    Private Shared mEventType As VolumeEventType

    Public Shared Sub ListenForChanges(Optional ByVal EventType As VolumeEventType = VolumeEventType.Any)
        mEventType = EventType
        Dim query2 As String
        If EventType = 5 Then
            query2 = "SELECT * FROM Win32_VolumeChangeEvent"
            query2 = "SELECT * FROM Win32_VolumeChangeEvent WHERE EventType=" & EventType
        End If
        ' Dim query2 As String = "SELECT * FROM __InstanceCreationEvent WITHIN 5 WHERE TargetInstance ISA ""Win32_USBHub"""
        MediaConnectWatcher = New System.Management.ManagementEventWatcher(query2)
    End Sub

    Private Shared Sub Arrived(ByVal sender As Object, ByVal e As System.Management.EventArrivedEventArgs) Handles MediaConnectWatcher.EventArrived
        Dim timeCreated As Date = Date.FromBinary(e.NewEvent("Time_Created"))
        Select Case e.NewEvent("EventType")
            Case 1
                RaiseEvent OnConfigurationChange(e.NewEvent("DriveName"), timeCreated)
            Case 2
                RaiseEvent OnArrival(e.NewEvent("DriveName"), timeCreated)
            Case 3
                RaiseEvent OnRemoval(e.NewEvent("DriveName"), timeCreated)
            Case 4
                RaiseEvent OnDock(e.NewEvent("DriveName"), timeCreated)
        End Select
        If mEventType = VolumeEventType.Any Then
            RaiseEvent OnAnyChange(e.NewEvent("EventType"), e.NewEvent("DriveName"), timeCreated)
        End If
    End Sub
End Class

The code below calls into ListenForChanges shared method to listen for any of the 5 standard volume events in windows but each event is handled separatly:

        Dim device As New RemovableDevice
    Private Sub Device_OnAnyChange(ByVal EventType As VolumeEventType, ByVal DriveName As String, ByVal TimeCreated As Date) Handles d.OnAnyChange
        MsgBox(EventType & DriveName & TimeCreated)
    End Sub

    Private Sub Device_OnArrival(ByVal DriveName As String, ByVal TimeCreated As Date) Handles d.OnArrival
        MsgBox("i am arrived")
    End Sub

    Private Sub Device_OnRemoval(ByVal DriveName As String, ByVal TimeCreated As Date) Handles d.OnRemoval
        MsgBox("i am removed")
    End Sub

    Private Sub Device_OnDock(ByVal DriveName As String, ByVal TimeCreated As Date) Handles d.OnDock
        MsgBox("i am docked")
    End Sub

    Private Sub Device_OnConfigurationChange(ByVal DriveName As String, ByVal TimeCreated As Date) Handles d.OnConfigurationChange
        MsgBox("my config is changed")
    End Sub