New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Stack trace clobbered when exception thrown by IAnswer impl #34

Closed
henri-tremblay opened this Issue Jun 3, 2015 · 0 comments

Comments

Projects
None yet
1 participant
@henri-tremblay
Contributor

henri-tremblay commented Jun 3, 2015

Migrated from: CodeHaus issue EASYMOCK-23
Original reporter: Henri Tremblay


I've implemented a custom IAnswer handler and set up my mock to return the the result computed by the IAnswer impl. Unfortunately, my IAnswer implementation had a bug in it, resulting in a NullPointerException being thrown. Problem is that it looks like MockInvocationHandler:34 (in v2.4) is replacing the stack trace of my NullPointerException with the stack trace generated at MockInvocationHandler:34. Here's the EasyMock code I'm referring to:

public Object invoke(Object proxy, Method method, Object[] args)
        throws Throwable {
    try {
        if (control.getState() instanceof RecordState) {
            LastControl.reportLastControl(control);
        }
        return control.getState().invoke(
                new Invocation(proxy, method, args));
    } catch (RuntimeExceptionWrapper e) {
        throw e.getRuntimeException().fillInStackTrace();
    } catch (AssertionErrorWrapper e) {
        throw e.getAssertionError().fillInStackTrace();
    } catch (ThrowableWrapper t) {
        throw t.getThrowable().fillInStackTrace();
    }
}

Here's my the stack trace from my test failure:

[junit] java.lang.NullPointerException
[junit]     at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:34)
[junit]     at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:61)
[junit]     at $Proxy6.getEmailInfos(Unknown Source)
[junit]     at com.linkedin.invitations.internal.impl.InvitationServiceImpl.getRecipientKeys(InvitationServiceImpl.java:297)
// snip: test code
[junit]     at test.fwk.util.core.BaseTestSuiteCore.run(BaseTestSuiteCore.java:139)

The reported NPE actually occurred further downstream in my IAnswer implementation. However, the resulting stack trace has erased those frames. I'd like the stack trace to look like this :)

[junit] java.lang.NullPointerException
[junit]     at com.linkedin.invitations.internal.impl.EOSAnswerFactory$1.answer(EOSAnswerFactory.java:91)
[junit]     at com.linkedin.invitations.internal.impl.EOSAnswerFactory$1.answer(EOSAnswerFactory.java:83)
[junit]     at org.easymock.internal.Result.answer(Result.java:60)
[junit]     at org.easymock.internal.ReplayState.invokeInner(ReplayState.java:41)
[junit]     at org.easymock.internal.ReplayState.invoke(ReplayState.java:33)
[junit]     at org.easymock.internal.MockInvocationHandler.invoke(MockInvocationHandler.java:27)
[junit]     at org.easymock.internal.ObjectMethodsFilter.invoke(ObjectMethodsFilter.java:61)
[junit]     at $Proxy6.getEmailInfos(Unknown Source)
[junit]     at com.linkedin.invitations.internal.impl.InvitationServiceImpl.getRecipientKeys(InvitationServiceImpl.java:297)

Perhaps I'm misunderstanding how fillInStackTrace() works, but it does appear to replace the existing stack trace. fillInStackTrace() is a native call, so perhaps my JVM (Mac) is screwing things up.

In any case, this clobbering of the stack trace is inconvenient in this scenario, as it looks like EasyMock internals are breaking, when it was really my own code. A debugger helped settle the matter, but it would have been faster to just see my code show up in the original stack trace. Is ther

Here's a similar, but seemingly unrelated bug I came across. It looks like it's a more general case of what I'm experiencing. Thanks for your help on this!

http://sourceforge.net/tracker/?func=detail&aid=824925&group_id=82958&atid=567837

@henri-tremblay henri-tremblay self-assigned this Jun 3, 2015

@henri-tremblay henri-tremblay added this to the 2.5 milestone Jun 3, 2015

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment