Reputation: 675
Sonarqube defines a rule saying Generic exceptions should never be thrown (i.e. throw a dedicated exception instead of using a generic one.) However AOP ProceedingJoinPoint always throws generic Throwable and normally I am not interested in the exception at all and just throw it from the method like this:
@Around(...)
public void someMethod(ProceedingJoinPoint point) throws Throwable {
// do something...
point.proceed();
// do something else...
}
Obviously this is against the above-mentioned Sonarqube rule. Do I really have to wrapper it with try catch and log the throwable or something? What is the best practice on this?
Upvotes: 4
Views: 2635
Reputation: 636
You can safely mark this violation as a false positive and enter a descriptive comment. This kind of false positive should be rare enough to allow you to treat them individualy, and act accordingly - AoP API is a good example, legacy and/or badly written libraries is another. But do NOT add the files to exclusions, as you would loose other rules from the Sonar analysis
Upvotes: 4
Reputation: 6474
It's true that you can't avoid to use libraries that throw Throwable
or plain Exception
s themselves. So there will always be an offend of that rule form sonarqube when you treat this Exception.
But you should definitely catch this Exception and do something with it. What exactly you do with it depends of the layer of your application that is catching it. If it's a lower one then you probably might want to wrap it into your own proper Exception. Consider that all other higher layers don't want to know which dependencies you use. If you are a high layer yourself then you could log it or return a proper message for the user. I hope this helps.
Upvotes: 0