Details
Description
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)
return control.getState().invoke(
new Invocation(proxy, method, args));
} catch (RuntimeExceptionWrapper e)
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
Activity
| Field | Original Value | New Value |
|---|---|---|
| Status | Open [ 1 ] | Closed [ 6 ] |
| Resolution | Fixed [ 1 ] |