3

Today, I discovered a few exception specifications in legacy code I've to maintain, when Cppcheck 1.68 ([Inconclusive] but correctly) pointed out that the specified exceptions are not handled in specific portions of the code.

[Inconclusive] Unhandled exception specification when calling function [...]. Either use a try/catch around the function call, or add a exception specification for [...] also.

But the occurrence of any of them would be catastrophic for the program, so it's a good idea not to handle them locally, and copying the specification over and over the code would be nonsense. And furthermore, exception specifications got deprecated in C++11 (for good reasons).

So, generally spoken: Is the best I can do with exception specifications, removing them?

3

Pretty much. There's no reason to keep them. I would strip them all out.

  • Thanks for letting me know. Is this only a personal feeling (BTW: I feel the same) or based on lots of bad experiences, or team decision, etc.? – Wolf Jan 6 '15 at 16:09
  • 1
    Possibly move them to the function comment block. – Tommy Andersen Jan 6 '15 at 16:44
  • Not a personal feeling at all, it's the best practice advocated by the people who standardized the language and write the compilers. See gotw.ca/publications/mill22.htm So why keep them? They're just noise in the code, and in fact can be worse than noise if they cause misunderstandings as shown in the linked article. – Rob K Jan 6 '15 at 19:14
  • 1
    I see, If you integrate the reference to your answer, I'll be happy to upvote it. – Wolf Jan 7 '15 at 10:37
  • @TommyA Why not add another answer? – Wolf Jan 7 '15 at 10:37
1

Exception specifications are not optimal in C++ as also mentioned in the link from Rob K by Herb Sutter, and therefore they are deprecated from the standard in C++11 see § 15.4.18.

Instead of using the exception specifications, an alternative could be to move them to the function comment block, in this way the information is not entirely lost. Don't underestimate the power of well written comments.

If for instance Doxygen was used one could easily use the throws or exception commands to describe the exceptions thrown by the function.

/**
 * Some function description.
 *
 * @throws SomeException In this or that situation this function will thrown an 
 * exception of type SomeException.
 */
void Foo();

In my opinion exception specification does not do any good (with the exception of the new noexcept) in C++, due to the problems mentioned by Herb Sutter (see link by Rob K), therefore your are better of removing them, but moving the information to a comment, for the function.

  • Fine, +1, maybe you should explicitly mention API-Doc, instead of just comments... (i.e. well-documented code instead of well written comments.) – Wolf Jan 7 '15 at 11:04
  • The problem with that sort of comment is that it has to be maintained. It becomes code duplication, and code that the compiler can't even check for you. I can't begin to tell you how many function comment blocks I've seen over the years that didn't match the code. – Rob K Jan 7 '15 at 14:28
  • @RobK In my experience, that often happens when there is already something wrong with the code you're commenting. If your function tries to perform too many tasks for instance comments easily become obsolete. But functions should be kept simple with few (preferably 1) responsibility, this should not change over time. What might change is the variety of exceptions thrown from the function, and even that is not recommendable. In this case it is a simple task of updating the comment. The code might be self explanatory, but not necessarily the reason behind it. – Tommy Andersen Jan 7 '15 at 14:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.