Bad error reporting

Describe the bug Due to https://github.com/gradle/gradle/issues/11795, there are problems with the used library versions, as much older versions needed by stuff in buildSrc win in the class path and then there are missing method exceptions.

This of course is not your fault and not what I report here. But the output in this case is sometimes super unhelpful, which is what I do report here.

A good example is a too old commons-io (1.3.1) that causes the build to fail with

Execution failed for task ':dependencyCheckAnalyze'.
> org.owasp.dependencycheck.analyzer.Analyzer: Provider org.owasp.dependencycheck.analyzer.ArchiveAnalyzer could not be instantiated`

and if run with -s reveals the Caused by: java.lang.NoSuchMethodError: org.apache.commons.io.filefilter.SuffixFileFilter.<init>(Ljava/util/List;Lorg/apache/commons/io/IOCase;)V cause.

A bad example is a too old guava that causes the build to fail with

Execution failed for task ':dependencyCheckAnalyze'.
> Analysis failed.

and if run with -s only says

Caused by: org.owasp.dependencycheck.exception.ExceptionCollection: One or more exceptions occurred during analysis:
        Unexpected Exception

which is pretty meaningless. After setting a breakpoint and assembling the stacktrace in Engine#analyzeDependencies I finally got the cause which is Caused by: java.lang.NoSuchMethodError: com.google.common.base.Preconditions.checkState(ZLjava/lang/String;Ljava/lang/Object;)V.

Version of dependency-check used The problem occurs using version 5.2.4 of the gradle plugin

[Vampire]

I’m not complaining about Gradle only showing the top-most message unless you use -s, that is normal and ok. I’m complaining about the stacktrace that you produce being totally unhelpful. This is not even dependency-check-gradle related, but dependency-check-parent related.

I’d say in ExceptionCollection which just assembles the messages of the top-most exceptions it got and nowhere the causes and stacktraces. The exception that came was with message Unexpected Exception and had as cause the NoSuchMethodError with the relevant information. But in the output, you only get the stacktrace of the ExceptionCollection and the top-most messages of the contained exceptions which does not help in any way to find the problem.

[danberindei]

@jeremylong since this issue is closed, is there another issue for reworking the overall exception handling?

@aikebah you say

Revisiting the addSuppressed documentation makes me reconsider… API contract of addSuppressed is for a different purpose - being able to swallow exceptions that happen after some initial exception that you intend to (re)throw at the end of error handling code.

But the addSuppressed() javadoc explicitly states that reporting multiple sibling exceptions as a single exception is a valid use case:

Note that programmer written code is also able to take advantage of calling this method in situations where there are multiple sibling exceptions and only one can be propagated.