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?

Improve this question

2 Answers 2

Reset to default
3

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

Improve this answer
5
  • 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.? Commented Jan 6, 2015 at 16:09
  • 1
    Possibly move them to the function comment block. Commented Jan 6, 2015 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. Commented Jan 6, 2015 at 19:14
  • 1
    I see, If you integrate the reference to your answer, I'll be happy to upvote it. Commented Jan 7, 2015 at 10:37
  • @TommyA Why not add another answer? Commented Jan 7, 2015 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.

Improve this answer
3
  • Fine, +1, maybe you should explicitly mention API-Doc, instead of just comments... (i.e. well-documented code instead of well written comments.) Commented Jan 7, 2015 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. Commented Jan 7, 2015 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. Commented Jan 7, 2015 at 14:35

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.