“Some exception classes are designed to be used only as base classes to more specific exceptions, for instance std::exception (the base class of all standard C++ exceptions), std::logic_error or std::runtime_error.
Catching such a generic exception types is a usually bad idea, because it implies that the “catch” block is clever enough to handle any type of exception.”
This rule makes it impossible to use 3rd party libraries that throw exceptions mentioned above.
The description says correctly that catching such exception is “usually” a bad idea. Not “always”.
So what do you do when the case falls out of the “usual” and you have to develop a high availability system?
Many of our rules have specific cases or domains where they are not applicable. Since we cannot satisfy all use cases with a single set of rules, we’ve introduced two ways to customize it:
Quality Profiles enable you to choose what rules are applicable to your entire project. By default, you are provided with the “Sonar Way” quality profile that is good enough for most projects. Note that it does not include all the rules Sonar is capable of detecting! If a rule does not make sense for your project, you can create your custom quality profile and exclude the rule from it.
Issue resolution keeps track of the individual issues in your code to spare you from having to investigate them over and over. If a rule does make sense for your project, but a particular issue does not, you can mark it
as “won’t fix” and explain why you think the rule is not applicable in the particular situation or
as “false positive” and explain why our analyzer made a mistake by raising the issue. In this case, please, do also open a topic here so that we can improve our analyzer.
It sounds like in your project, you might want to create a custom quality profile and exclude S2738 (and potentially S1181) from it.