Using thenThrows(new SomeThrowable) in multi-threaded context results in ArrayIndexOutOfBoundsException

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Mock some method and use thenThrow(new SomeThrowable()).
2. Use mocked method in several threads.

What is the expected output? What do you see instead?
Only SomeThrowable should be thrown when method is used. Instead 
java.lang.ArrayIndexOutOfBoundsException is thrown.

What version of the product are you using? On what operating system?
mockito-core-1.9.0.jar
java version "1.6.0_31"
Java(TM) SE Runtime Environment (build 1.6.0_31-b05)
Java HotSpot(TM) Client VM (build 20.6-b01, mixed mode, sharing)

Please provide any additional information below.
I attached MultithreadedThenThrowsTests JUnit test case to reproduce this in 
mockito. I also attached ThrowableThreadSafetyTest to show what sequence of 
method invocations on Throwable causes this. Problem is in Throwable which 
depends on JVM. However mockito should have a workaround for people who are 
stuck with problematic JVMs. Someone proposed to have a new method that takes 
factory to create new exceptions: .thenThrowNew(new 
ExceptioFactory().createException(...));

Original issue reported on code.google.com by vadim.kl...@gmail.com on 12 Nov 2012 at 6:02

Attachments:

• MultithreadedThenThrowsTests.java
• ThrowableThreadSafetyTest.java

[GoogleCodeExporter]

Hi,

Sorry for the delayed answer, pretty busy at the moment. Actually there is a 
similar API in mockito, thenThrow(SomeThrowable.class), it uses objenesis to 
instantiate the exception class at the interaction time. 

If that doesn't suit your needs, you can still create your own answer that will 
create the exception you want.

So I don't think we will solve the issue with the ExceptionFactory you 
mentioned, as there is already similar feature.
How does that sounds ?

Cheers,
Brice

Original comment by brice.du...@gmail.com on 27 Nov 2012 at 4:52

[GoogleCodeExporter]

Hi,
We resolved our issue by using custom answer that throws an exception. Thank 
you for the hint.
Vadim

Original comment by vadi...@gmail.com on 7 Dec 2012 at 5:53

[GoogleCodeExporter]

Nice, i'll change the status of the issue then

Cheers,
Brice

Original comment by brice.du...@gmail.com on 7 Dec 2012 at 9:02

• Changed state: WontFix

[GoogleCodeExporter]

Hmmm, it might be nice fix this bug at some point.

Original comment by szcze...@gmail.com on 7 Dec 2012 at 11:16

[GoogleCodeExporter]

I would say it's not even a bug in mockito in the sense there is already two 
features that allows code to not be impacted by that error.

Also Exception were never made to be thread safe! Throwing an exception 
multiple time already seems wrong.

Eventually you can create your own ThrowsExceptionAnswer factory.

Original comment by brice.du...@gmail.com on 7 Dec 2012 at 1:11

• Added labels: Type-Enhancement
• Removed labels: Type-Defect

[GoogleCodeExporter]

Yeah, possibly. I think that if the exception comes from the way we handle 
exceptions (for example, init cause, stack trace filtering, etc.) then it's 
nice if Mockito handles the scenario best it can. For that I would need to see 
the stack trace :) Anyhow, I don't think this has high priority in any case.

Original comment by szcze...@gmail.com on 7 Dec 2012 at 3:30

[GoogleCodeExporter]

Good point I forgot about that.

OK I double-checked the code sample code, it executes fine on the JDK7, and 
fails on the JDK6.

The code in the JDK7 is more robust regarding concurrency issues (impacted code 
is for example : getCause, printStackTrace, fillInStackTrace, getOurStackTrace, 
setStackTrace)

Still it would be good to craft an example with mockito. Reopening the issue

Original comment by brice.du...@gmail.com on 7 Dec 2012 at 4:30

• Changed state: New