#21 Don't let exceptions kill the build

[Nascif Abousalh Neto]

When using Clirr to create reports, failures related to the class loading (missing jars or classes) would be better reported with the remaining errors to stdout or the output file - perhaps a special category called "FAILURE" could be created to support those.

The fact that those errors kill the Clirr process and dump a stack trace to stderr makes them it hard to integrate Clirr with other tools through automated scripts to generate reports.

Thanks,
Nascif

[Lars Kühne]

Logged In: YES
user_id=401384
Originator: NO

I didn't find any calls to System.exit() in the core checker code.
Which frontend are you using (Commandline/Ant/Maven) and what do you mean by "kill the Clirr process"?

[Nascif Abousalh Neto]

Logged In: YES
user_id=263845
Originator: YES

I am using the command-line - have not tried the others.

By killing the process I mean not handling runtime errors when running clirr, and calling System.exit. This is not so bad for me now because I am calling Clirr multiple times, one for each jar, since I want to be able to group the generated messages.

But the output to stderr and the stack traces for uncaught exceptions are problematic.

[Lars Kühne]

Logged In: YES
user_id=401384
Originator: NO

Well, the core engine can't do anything useful when jars or classes are missing, so I think it's OK to bail out with an exception. In Checkstyle (where I'm also a committer) we report setup problems along with all the code problems we find, and this causes an endless stream of support requests. I'd like to avoid that mistake in Clirr.

If you look at the code for the clirr command line frontend in net.sf.clirr.cli, you'll find that it catches some expected exceptions and sets the exit code only in the main method. I should add a catch block for RuntimeException, that is currently missing, and that is why you see stack traces. Good catch :-)

[Nascif Abousalh Neto]

Logged In: YES
user_id=263845
Originator: YES

This is kind of what I did in my hacked version of the cli launcher - but I print those out to stdout in a format similar to a regular error, but using a fake category "FAILURE" instead. I think I agree more with the Checkstyle approach - it is unfortunately very common to see problems with wrong classpaths and missing classes creeping from the environment to the tool execution, and it is not easy to recover if the tool won't handle those gracefully.

[Lars Kühne]

Logged In: YES
user_id=401384
Originator: NO

Oh, and I'd love to see the stack trace that you are getting. Having RuntimeExceptions propagating all up to the container is likely a bug.

[Nascif Abousalh Neto]

Logged In: YES
user_id=263845
Originator: YES

This is kind of what I did in my hacked version of the cli launcher - but I print those out to stdout in a format similar to a regular error, but using a fake category "FAILURE" instead. I think I agree more with the Checkstyle approach - it is unfortunately very common to see problems with wrong classpaths and missing classes creeping from the environment to the tool execution, and it is not easy to recover if the tool won't handle those gracefully.

[Nascif Abousalh Neto]

Logged In: YES
user_id=263845
Originator: YES

Here they are.

java.lang.ClassNotFoundException: antlr.TreeParser not found.
at net.sf.clirr.core.internal.bcel.BcelJavaType.getAllInterfaces(BcelJavaType.java:88)
at net.sf.clirr.core.internal.checks.InterfaceSetCheck.check(InterfaceSetCheck.java:59)
at net.sf.clirr.core.Checker.runClassChecks(Checker.java:190)
at net.sf.clirr.core.Checker.reportDiffs(Checker.java:136)
at net.sf.clirr.cli.Clirr.run(Clirr.java:155)
at net.sf.clirr.cli.Clirr.main(Clirr.java:56)
Caused by: java.lang.ClassNotFoundException: antlr.TreeParser not found.
at org.apache.bcel.util.ClassLoaderRepository.loadClass(ClassLoaderRepository.java:91)
at org.apache.bcel.classfile.JavaClass.getSuperClass(JavaClass.java:762)
at org.apache.bcel.classfile.JavaClass.getAllInterfaces(JavaClass.java:803)
at net.sf.clirr.core.internal.bcel.BcelJavaType.getAllInterfaces(BcelJavaType.java:86)
... 5 more
= xyz.framework.workspace.jar ============================================================

clirr: xyz.rpf.jar
Exception in thread "main" java.lang.Error: java.lang.ClassNotFoundException: com.ibm.security.auth.PrincipalComparator not found.
at net.sf.clirr.core.internal.bcel.BcelJavaType.getAllInterfaces(BcelJavaType.java:88)
at net.sf.clirr.core.internal.checks.InterfaceSetCheck.check(InterfaceSetCheck.java:59)
at net.sf.clirr.core.Checker.runClassChecks(Checker.java:190)
at net.sf.clirr.core.Checker.reportDiffs(Checker.java:136)
at net.sf.clirr.cli.Clirr.run(Clirr.java:155)
at net.sf.clirr.cli.Clirr.main(Clirr.java:56)
Caused by: java.lang.ClassNotFoundException: com.ibm.security.auth.PrincipalComparator not found.
at org.apache.bcel.util.ClassLoaderRepository.loadClass(ClassLoaderRepository.java:91)
at org.apache.bcel.classfile.JavaClass.getInterfaces(JavaClass.java:788)
at org.apache.bcel.classfile.JavaClass.getAllInterfaces(JavaClass.java:804)
at net.sf.clirr.core.internal.bcel.BcelJavaType.getAllInterfaces(BcelJavaType.java:86)
... 5 more
= xyz.rpf.jar

[Lars Kühne]

Logged In: YES
user_id=401384
Originator: NO

The catch block for RTE has been added in CVS.

Thanks for the stacktraces, this is an error I can't reproduce in the current code base because I switched from bcel to asm.

Re the failure reporting: I understand your position, but I think it's better to clearly signal an unrecoverable problem and then fail the build. This forces the user to provide a correct classpath which is the long term solution anyway, instead of forcing all tools in the toolchain to deal with situations where they can't really do anything useful.