ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 43398] New: - Ant discards stack traces for random exceptions terminating a build
Date Fri, 14 Sep 2007 15:33:53 GMT
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: jglick@netbeans.org
        ReportedBy: jglick@netbeans.org
                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: dev-unsubscribe@ant.apache.org
For additional commands, e-mail: dev-help@ant.apache.org


Mime
View raw message