Best Practices: Handling disconnects of hardware in classes that represent them

I'm working in VB.Net developing data logging software. I've developed classes implementing a common interface that works with many of the data loggers my company produces. These classes handle the low-level hardware interfacing and expose common methods for accessing the data logger's records.

My issue is what would be a good practice to handle someone suddenly disconnecting the hardware? Should I throw an exception, raise an event, or return false in some sort of status packet?

My basic thought is that I want the object to notify the sender when the device it represents is disconnected and to fail and then somehow communicate to the DeviceLocator class (which auto-detects devices and maintains a collection) that it has been disconnected 开发者_如何学运维and to remove it from the collection of devices and dispose.

Any tips?

---

At a high level, I think you should return a result code or an error message from your "driver" layer. Down the road you may want to expose the data packets to different types of clients. If you have a WCF client, or a mobile client calling web services, throwing an exception or raising an event is of no use. You would have to create another layer that catches these conditions and translates them for each client, so why no do this at the lowest possible level.

A more detailed answer depends on your actual architecture. Do you use delegates, for instance, to notify a consumer of new data? Why not have a delegate that is being called when there is an error condition.