Is your feature request related to a problem? Please describe.
We currently have a type ConfigError that is supposed to be part of Report objects. This has very limited usefulness for now. Only a couple of rules actually do some validation that can end up as a config error. Validation of properties in the XML does not, for instance. Config errors are badly supported by renderers (#194) and by pmd integrations like the maven plugin (quoting #1371). They're ignored almost everywhere.
I think "configuration errors" are a superflous concept that we shouldn't support at all. A configuration error is an error in the user-supplied configuration of PMD, eg invalid properties or invalid classpath. There is conceptually no difference between this and eg validating command line arguments. Currently a lot of validation is done in PMD by logging a message, and throwing an exception and letting the calling code catch it. Comparatively few places have access to a report and we couldn't transform everything to put config errors into a report. Nor would this be sensible: what good would a report be that only has one error because we couldn't continue executing the program.
Describe the solution you'd like
I think we should
- improve on our logging facilities, but not use a report as the output of our errors and diagnostic warnings about configuration. We just need to distinguish recoverable and fatal errors. A wrong auxclasspath is recoverable, and we can log a warning about it which will prompt the user to fix their configuration. Wrong properties could actually be treated as non-recoverable: we already do it for non-existent properties, so why does LooseCoupling create a ConfigError for what is the same kind of error?
- Remove ConfigErrors from the codebase and from Report
Describe alternatives you've considered
Additional context
Is your feature request related to a problem? Please describe.
We currently have a type ConfigError that is supposed to be part of Report objects. This has very limited usefulness for now. Only a couple of rules actually do some validation that can end up as a config error. Validation of properties in the XML does not, for instance. Config errors are badly supported by renderers (#194) and by pmd integrations like the maven plugin (quoting #1371). They're ignored almost everywhere.
I think "configuration errors" are a superflous concept that we shouldn't support at all. A configuration error is an error in the user-supplied configuration of PMD, eg invalid properties or invalid classpath. There is conceptually no difference between this and eg validating command line arguments. Currently a lot of validation is done in PMD by logging a message, and throwing an exception and letting the calling code catch it. Comparatively few places have access to a report and we couldn't transform everything to put config errors into a report. Nor would this be sensible: what good would a report be that only has one error because we couldn't continue executing the program.
Describe the solution you'd like
I think we should
Describe alternatives you've considered
Additional context