I’m writing a C++ class. Some of its fields are STL containers, some aren’t. While writing the methods I began wondering, how should I handle invalid values passed to methods? For example, some methods are more or less wrappers to STL container methods. Many STL methods just have “undefined behavior” when invalid iterators are passed. I guess it’s like that because it allows the STL code to ignore these cases and thus be faster.
But for higher level code, what should I do? I do throw exceptions when an unexpected error occurs, for example an error made by a mistake a developer made. But in this case the parameter value depends on the interface user, not on the implementor. I could ignore invalid parameters and invalid iterators, etc. and “pass” the problem to lower-level functions, which would then have undefined behavior, but I could also throw an exception or at least find some way to report an error.
What would be the best thing to do?
Example: I have a class representing a tree node and it has a method add_child() which takes a std::shared_ptr parameter. Should I check the value or let the user make sure a nullptr isn’t passed? Or for an invalid iterator, pass it to STL methods or report an error? If I should report – are exceptions the right solution?
I think a universal answer cannot be given. Too many things affect the decision that you haven’t mentioned: first of all, are you developing a library or an application?
In the first case, flexibility should be favored and the best choice is usually to design your interface in a way that leaves the decision up to the client. Since you don’t know what clients will use your class and which requirements they will have, it’s best to make as few assumptions as possible. If your clients have tight performance requirements, they won’t be willing to pay the performance penalty of an extra bounds check, for instance. This is, basically, the reason why bound checks are not performed by STL either.
In the second case, it depends on the performance requirements of your application and the exception safety guarantees your class has to provide. Which operations need to be no-throw? Are you allowing or planning to use your class inside an STL container? Is it going to be used in the most critical part of your application, so that a small performance performance gain in the algorithms of this class will affect the overall execution time of your application?
There is no such a thing as a “universally best design”. Engineering is all about finding the right compromise according to the particular situation at hand, and software engineering is no exception to this.