Question

I am writing a class library that wraps different objects
(mostly device drivers for USB hardware components)

Some classes of these device drivers expose an event of kind “OnError”: in short if a runtime error or other error occured in the device driver then the event is fired. Something like:

    AddHandler oDevice.DriverRunTimeErrorEvent, 
               AddressOf HandleDriverRunTimeErrorEvent

    Private Sub HandleDriverRunTimeErrorEvent(
                ByVal sender As Object,
                ByVal eventData As DriverRunTimeErrorEventArgs)
        'handle the error
    End Sub

Positive of this solution is that if an error occurs, the program is not stopped, but I will never know what is happened if I do not use the event.

Now, wrapping the device driver in my class library I have to think what I have to pass to the client that will use my class library and if I should do.

1. I could forward the device driver solution and generate a new event in the class library. Then the client should handle the forwarded event.

2. But I could also throw an exception with all error information

3. I could simply ignore the error and just log it in a protocol file.

The solution 1. seems to be more robust to me and I would use it, but it is not “near” to the .NET world.

The solution 2. throws an error asynchronously with the program flow: in the client application I would not have any try-catch block that could trap it. In other words the class could throw an error without the client having called any method of the class.
Of course I could trap all the errors at application level, but anyway this introduces some fuzziness in the logic that I would prefer to avoid.

How would you handle these OnError events?

Answer 1

Option 3 you should always do, independently of your choice of approach to present the errors to users – of course if it’s reasonably achievable, i.e. if you have write access to storage big enough to hold the logs.

Choosing between 1 and 2 depends on the general approach you pick to deliver error information to your users. In the .NET world throwing exceptions is preferred, at least in standard situations, and by standard I mean if your interface is synchronous. If your users are calling a method of your class and wait for you to return a value (or simply finish execution) – then you should throw an exception if something wrong ‘enough’

You may need to steer away from throwing exceptions in some cases, one being if the interface you provide to clients is asynchronous. If they call your method and you return immediately, leaving a worker thread in the background – then throwing exceptions is simply not an option and you need to add a similar event-based approach to let your clients subscribe for error information – if they need it! That’s something that you need to decide (unless you post more details about the nature of your project) – if you can get away with just logging errors to a file then why bother raising events?

There is another reason why you may need to implement error notifications not based on exceptions. You may still have a synchronous model – clients call you and wait for your operation to complete – and then you can (and you should) use events to notify the caller that the operation could not come to a successful conclusion. But you may have distinction between something going ‘wrong enough’ and ‘mildly wrong’. Consider the following scenario:

The client calls a method, you start an asynchronous operation, but at some point start waiting for it to complete, e.g. with Thread.Join or WaitHandle.WaitOne. When the worker thread eventually finishes you return the result to the user. You may subscribe to an error event from the underlying framework – but you may identify this error as non fatal, so instead of throwing an exception you may decide to continue waiting for the background thread to finish, but notify the user about the error anyway (again – only if you need to, quite often you can get away by simply logging). You can do this either by means of events, or by a return value (or ref/out parameter). The latter is the more mainstream approach – you just return a list of non-fatal errors, that in most cases will be empty, and if the client cares – he’ll go over the list.

That’s it pretty much, it depends mainly on your class library’s interface – is it synchronous or not, if you share more details on that you can get more specific answers.