I have a driver for a remote device, and the driver communicates with the device via socket. The driver has properties that clients can use to get information about the device. Every property uses the driver’s private read/write method to send a query to the device and wait for a response.
I’m trying to determine the best way to handle socket exceptions. Specifically, when the client uses one of the properties to get information about the device, I have to rethrow exceptions that occur in the read/write method, otherwise, the client would receive a default value, without knowing something went wrong.
Are there any design patterns or common approaches to this type of issue? It seems a bit tedious to handle exceptions anytime a client uses the driver properties. But then again, the only work around I see is to have a boolean HasError property on the driver. This is really just an indirect workaround to actually throwing an exception and having the client catch it.
You should interpret the socket exceptions and rethrow something more informative for the client: they don’t want to have to think about socket problems. If your exceptions don’t map onto any existing exceptions very well, create your own exception type and return informative messages such as “there is a problem with the network connection” rather then something like “socket read error”.
e.g.
You could of course add some details from the SocketException to your own message for debugging purposes.
Exceptions are still definitely the way to go, but you want to give your client meaningful messages in their context, rather than yours. After all, when you use the socket classes you get SocketExceptions: not NDIS exceptions or whatever, which would mean nothing to you.