While “Deprecated” code should not be used (java:S1874) is almost always excellent advice there are some niche cases that would benefit from the ability to exclude specific deprecated methods and/or classes at the rule set level because sometimes projects deprecate classes and methods to state an intention to eventually replace… well before there is an actual replacement. For instance, Hibernate Query.setResultTransformer is deprecated and marked with " todo develop a new approach to result transformers". Yes, I can turn off the rule or mark every instance with // NOSONAR (or use suppresswarnings) but I’d really like a more principled solution when libraries abuse deprecate in this way.
1 Like
Hello @Michael_Thome,
The problem is that to introduce these type of exceptions, you would need to keep track of a specific deprecated component and when SQ should start raising issues on its use again.
While this could work to suppress the issues you are facing, they would require extra maintenance and shared knowledge among the team of the exception mechanism.
You are probably better off using NOSONAR, marking these issues as “wont-fix” or wrapping the deprecated component in a custom component to limit the number of issues raised.
With the exception living close to the source code (or in the path of the developer/reviewer), it is easier to reason about its relevance.
Hope this helps,
Dorian