C# – Confused about when to throw an exception

.netc++exception-handling

I am working on a library designed to communicate (over RS232 serial communication) with external devices. I was thinking about error handling strategy and exceptions seemed to be right and industry standard way of reporting errors.

So I read few guidelines on exceptions. One pretty clearly states that I should not worry about performance hit:

Do not use error codes because of concerns that exceptions might affect performance negatively.

Other told me NOT to throw exception in normal cases:

Do not use exceptions for normal or expected errors, or for normal flow of control.

I am not able to draw clear line between normal/expected and other cases. For example in my library, a operation may fail because:

  1. There is no response from device. (no cable connected, device not turned on, wrong baud rate)
  2. Operation request is rejected by device because it couldn't authenticate the request.
  3. Communication failed in between. (someone tripped over the cable, device was powered off suddenly).

I can think all above as expected problems because they can happen in practice very often (infact many marketing morons call me to solve the ^problem^ in my software only to find out they didnt connect the cable to their laptop). So may be exceptions should not be thrown because otherwise application programmer will have to catch those at plenty of places (a lot of catch blocks are also NOT nice to have I believe).

On the other hand, I also tend to think that these are all errors which I somehow need to report to application programmer, and exception seems to be the way to do that. If I don't use exceptions, I will need to report these problems using some error code or error enums. (ugly, I know).

Which approach do you think I should take?

Best Solution

You are developing a library, a component that will be utilized by other applications.

Therefore in the expected cases you mention I would certainly use exceptions to communicate to the calling application that something is amiss. You should define a custom exception for each of these scenarios and then clearly document when they may occur.

This then allows the application client code to make the decision as to how best to proceed. Only the client application can make this decision and clearly documented exceptions greatly aid this.

The best thing about a custom exception is that you can provide multiple meaningful / useful pieces of data relating to the problem/exception. This data is also nicely encapsulated in one object. Compare this to error codes and return values.

Performance can be an issue but only when the exception is thrown within a tight loop or some other high activity situation. To avoid this you could also apply a pattern used by the .NET Framework, namely provide Try....() methods (eg TryParse()) that return boolean indicating if an action succeeded or failed.

Either way I would go with custom exceptions initially, and then do performance testing to actually see if there are certain parts of the library that may need optimization.

Related Question