Question

I know that exception driven programming is something that shouldn’t be done (and I imagine why).
I’m building a library where I have to estabilish a connection with a device, so the programmer will call MyDeviceInstance.Connect on some point and now is where my problem shows up.

I wrote my connect methods as void Connect(), so I’m not returning anything (because actually I don’t need anything), but I will throw exception in a lot of situations:

1. If connection already exists
2. If there are some wrong settings in MyDeviceInstance
3. If my interop method deviceConnect will fail (and here is the biggest problem, because it will returns an int that represents a lot of errors)

Should Connect returns a boolean instead of void?There will be a lot of possibilities that I’ll throw an exception.

The second part of this question is on another method, called void Update(). This method can works only if MyDeviceInstance is already connected. In this case I’ll throw exceptions when:

1. Connection doesn’t exist
2. Connection is lost for any reason (and the programmer will not expect this will happen, but can)
3. Other interop errors

Should update returns a bool value instead of throwing all those exceptions (at least, to limit common errors like “connection doesn’t exist”)?

Thanks for any answer

EDIT 1:

I have to be more precise on one point: because we are talking about an USB device, when I’ll call my method Update, this method could fail depending on the device (if is connected or not). More important, if I reconnect the device the interop method will start working again (and the normal method will do the same), without needing a reconnection or things like that (I don’t know how this is working internally).

For update methods, should I throw if the device is disconnected? Programmatically speaking this is an exception, but user-speaking this will be a quite-normal situation.

Answer 1

If the code which calls a method will be prepared to deal with unusual results, the method should indicate unusual results via some means other than exceptions. If the calling code will not be prepared to deal with unusual results, then such results should cause exceptions. Unfortunately, there’s no way for a class to magically know whether the caller is going to expect unusual results unless the caller tells it somehow. A common pattern in .net is for a class to provide pairs of “DoSomething” and “TryDoSomething” methods:

ResultType DoSomething();
Boolean TryDoSomething(ref ResultType result);

Frankly, I think the latter formulation would be better expressed as:

ResultType TryDoSomething(ref Boolean ok);

or perhaps:

ResultType TryDoSomething(ref Exception ex);

where “ex”, if non-null, would indicate that an exception (ex) would have been thrown by DoSomething (but with a blank stack trace, since the exception won’t actually have been thrown). Another pattern in some cases may be:

ResultType TryDoSomething(Action failureAction);

If an unexpected situation arises, the code will call the indicated delegate, with a parameter providing details of the context where the situation arose. That delegate may be able to allow for better error handling and recovery than would otherwise be possible, since it could be called before TryDoSomething gave up on whatever it was doing. For example, it could direct TryDoSomething() to keep retrying the operation unless or until the object supplying the delegate receives a cancel request.