DO NOT REPLY TO THIS EMAIL, BUT PLEASE POST YOUR BUG· RELATED COMMENTS THROUGH THE WEB INTERFACE AVAILABLE AT <http://issues.apache.org/bugzilla/show_bug.cgi?id=43398>. ANY REPLY MADE TO THIS MESSAGE WILL NOT BE COLLECTED AND· INSERTED IN THE BUG DATABASE.
http://issues.apache.org/bugzilla/show_bug.cgi?id=43398 Summary: Ant discards stack traces for random exceptions terminating a build Product: Ant Version: 1.6.5 Platform: All OS/Version: All Status: NEW Severity: major Priority: P2 Component: Core AssignedTo: [EMAIL PROTECTED] ReportedBy: [EMAIL PROTECTED] CC: dev@ant.apache.org This bug is so old I always thought it was "as designed", irritating as it was. But no, it seems to be an accident. ---%<--- $ cat /tmp/x.ant; /space/ant165/bin/ant -f /tmp/x.ant <project default="x"> <target name="x"> <echo file="X.java"> public class X extends org.apache.tools.ant.Task { public void execute() { throw new NullPointerException("huh?!"); } } </echo> <javac srcdir="." destdir="." includes="X.java" debug="true"/> <taskdef classpath="." classname="X" name="x"/> <x/> </target> </project>Buildfile: /tmp/x.ant x: [javac] Compiling 1 source file to /tmp BUILD FAILED /tmp/x.ant:12: java.lang.NullPointerException: huh?! Total time: 1 second ---%<--- (Similar in 1.7.0; 1.6.5 was the oldest version I had lying around to test.) Note the lack of a stack trace which would give you any clue where the NPE was thrown or why. Of course you can run with -v to get the stack trace, but 1. This also sends lots of other output which you may not have needed. 2. That is no comfort if the problem happened unreproducibly on a continuous builder. Generally a BuildException thrown from a task is a "normal" error in script configuration, with some kind of explanation, but any other exception is probably a bug in the task and a stack trace would be useful. DefaultLogger has this code which looks like it should work: if (Project.MSG_VERBOSE <= msgOutputLevel || !(error instanceof BuildException)) { message.append(StringUtils.getStackTrace(error)); In fact it doesn't; DispatchUtils.execute catches the NPE (or whatever) and wraps it in a BuildException! So the second part of the test is _never_ true. One possible patch would be to change DU.execute to rethrow all RuntimeException's (not just BuildException) unwrapped. This may work but I somewhat prefer the attached patch as it should be more resilient to other code wrapping things in uninformative BuildException's. This will show a stack trace: try { ... } catch (Exception x) { throw new BuildException(x); } This will not show a stack trace without -v (assumes the task's message is enough diagnosis): ...throw new BuildException("Problem opening " + file, x); -- Configure bugmail: http://issues.apache.org/bugzilla/userprefs.cgi?tab=email ------- You are receiving this mail because: ------- You are on the CC list for the bug, or are watching someone who is. --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, e-mail: [EMAIL PROTECTED]
