Please add your comments and proposals for the problems listed below.
 | Suggested form of voting for existing proposals :
|
Problems to be addressed :
Checked or unchecked exception ?
Generally in Sonar we don't like checked exception, however in case of unchecked exception how to understand that it should be catched in order to be handled or wrapped ? Example :
Fabrice Bellingard : maybe we should have 1 single exception that we could use in such case, like SonarFunctionalException (<= this name is bad, this is just to tell the fact that this is something "planned" and that it should be handled by consumer)
Evgeny Mandrikov : I didn't understand - should this exception be checked ? If so, then I'm not sure, because in such case we are going to mix checked / unchecked exceptions and this may lead to a mess in code. According to Josh Bloch, Effective Java: "Item 40: Use checked exceptions for recoverable conditions and runtime exceptions for programming errors. Item 41: Avoid unnecessary use of checked exceptions. In other words, don't use checked exceptions for conditions from which the caller could not possibly recover, or for which the only foreseeable response would be for the program to exit." and in most Sonar cases we deal with unrecoverable conditions, which should lead to an exit.
Not enough contextual information in place, where exception should be thrown
Example :
Proposals
Evgeny Mandrikov : from my point of view this actually means that in any case we can't leave without re-wrapping, but this should be done more carefully.
May lead to a stack trace, without contextual information on top
Example http://markmail.org/message/hzgxnrdbib26lsms , which is implemented like :
Proposals
Evgeny Mandrikov : maybe extend SonarException to allow something like :
So to produce on top level, something like :
if root cause SonarException and chain contains a lot of wrappers :
Failed to execute CPDSensor Unable to parse file: filename Unknown token: ... stack-trace for root cause
if root cause FileNotFoundException and chain contains a lot of wrappers :
Failed to execute CPDSensor Unable to parse file: filename File not found stack-trace for root cause
May lead to a huge full stack trace
For now seems to be typical that exception from Sonar contains more than 3 levels of wrapping.
Proposals
Simon Brandhof suggested to use Logback feature - limit the depth of stacktrace with the option "throwable{depth}", for example "throwable{5}". It also could be useful for JRuby long stacktraces.
Evgeny Mandrikov : +1 for JRuby, +0 for Java, because IMO would be better to not hide full stack-trace and have an ability to read it, however top level information must be improved in a way that will not be necessary to read full stack-trace.
Labels
