ant-notifications mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From bugzi...@apache.org
Subject DO NOT REPLY [Bug 45631] New: JUnit stack trace filtering hides AssertionErrors
Date Thu, 14 Aug 2008 11:27:45 GMT
https://issues.apache.org/bugzilla/show_bug.cgi?id=45631

           Summary: JUnit stack trace filtering hides AssertionErrors
           Product: Ant
           Version: 1.7.0
          Platform: All
        OS/Version: All
            Status: NEW
          Severity: normal
          Priority: P2
         Component: Optional Tasks
        AssignedTo: notifications@ant.apache.org
        ReportedBy: ben.rowlands@morganstanley.com


Ants JUnit runner filters stack traces to keep them succinct by removing the
guts of Ant/JUnit. However it unconditionally removes lines matching:

  "Caused by: java.lang.AssertionError"

See JUnitTestRunner#DEFAULT_TRACE_FILTERS

This makes interpretation of stack trace caused by a assertion error difficult.
For example, I have a test:

public class MyTest {
    private void doSomething() {
        try {
            // silly example, but this may be deep in some code
            assert null != null;
        } catch (Throwable t) {
            throw new RuntimeException("Caught exception...", t);
        }
    }

    @Test
    public void test() throws Exception {
        doSomething();
    }
}

The exception logged by Ant is:

1.  java.lang.RuntimeException: Caught exception...
2.    at tests.MyTest.doSomething(MyTest.java:12)
3.    at tests.MyTest.test(MyTest.java:18)
4.    at tests.MyTest.doSomething(MyTest.java:10)

This is very confusing. The "Caused by" line is missing (it should be after
line 3). 

The *real* stack trace (this is what the Eclipse JUnit runner reports) is:

1.  java.lang.RuntimeException: Caught exception...
2.    at tests.MyTest.doSomething(MyTest.java:12)
3.    at tests.MyTest.test(MyTest.java:18)
4.  Caused by: java.lang.AssertionError 
5.    at tests.MyTest.doSomething(MyTest.java:10)

Note, line 4 shows the cause.

A simple workaround is to disable the 'filtertrace' property so no 'cleaning'
of the stack trace is performned, however I like the filtering and filtering
out this cause seems to be a bug.


-- 
Configure bugmail: https://issues.apache.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are the assignee for the bug.

Mime
View raw message