Question

For the software we’re developing at the company that I work for, we use a third-party library which is developed by a guy that we’re constantly in contact with. His code is written in C++, and we use C# in the project.

Normally, his library functions return error codes. I decided to have different exception classes to cover different ranges of error codes. For example, one exception class for parameter handling errors, one exception class for main operation errors, one exception class for input value errors and so on.

He thinks it’s not a good idea, and suggests using one exception class for the library that catches all the errors, and then fetches the error code from an XML file and outputs the problem to the user. He thinks, it’s pointless to write more than one exception class. And also he says that he can’t promise that the error codes will be the same in different versions of the library.

I think it’s a good idea to have more than one exception class because:

1. There may be different situations that we need to handle the problem differently. Maybe when there’s a parameter exception, do other stuff than just outputting an error. But he thinks his library is handling everything, and we should just stop the operation and output an error. I also can’t think of many concrete examples of cases we need to handle differently, other than showing an error message. But I feel we may need it, and I’m afraid that I’m just violating the YAGNI principle.
2. I think if he turns out wrong, and we need to handle things differently in different cases, I’ll have to introduce conditional code (if error was A then do this, if B then do that). And it will be difficult to handle.

I think it’s a better idea to develop the program in a way that we can handle different types of exceptions differently. But then the guy has much more experience than me, plus he has much more credibility in the company (I’m a new intern) and I’m pretty new to software development and I feel like maybe he’s right and I’m just trying to add extra code because it looks pretty, and violating the YAGNI principle.

Do you think we should go with one class or more? And if you think we should use more than one exception class, what are your reasons?

Answer 1

If the error codes can change from version to version, then no amount of work (or lack of it) is going to save you trouble of having to remap these somehow at some point. If you have exceptions for codes (or code ranges) then it’s hardly going to be much more work than if you didn’t have, when error codes do change (you’re going to be rearranging what exceptions are thrown, just as you would have to be jiggling the messages around for one exception if you didn’t have dedicated classes).

Besides, in general practice, by .NET convention, you should create a dedicated exception class for specific exceptions that aren’t aptly covered by BCL-provided exceptions (excluding use of the some in there that are meant for abstraction only).

For some Microsoft input, consider this:

Applications and libraries should not use return codes to communicate errors.

And this:

Consider throwing existing exceptions residing in the System
namespaces instead of creating custom exception types.

But, following the Exception Design Guidelines,

[will] help ensure that you use the existing
exceptions, where appropriate, and create new exceptions where they
add value to your library.

Stick to your guns.