Join GitHub today
GitHub is home to over 50 million developers working together to host and review code, manage projects, and build software together.Sign up
GitHub is where the world builds software
Millions of developers and companies build, ship, and maintain their software on GitHub — the largest and most advanced development platform in the world.
TCK assertions wrong for Cache.invoke and wrapped exceptions #85
TCK challange for:
The TCK entry processor in these tests produces the following exception:
and asserts that an exception will be thrown by invoke with cause java.lang.IllegalAccessError e.g. by:
The EntryProcessorException documentation states:
This also applies to this type of exception itself.
Is the Spec enforcing that an EntryProcessorException must be passed on directly?
Change the TCK to test that an exception is wrapped by the cache implementation.
Change the TCK not to expect that the original exception is the immediate cause, but the root cause.
I am currently verifying tCache from https://github.com/trivago/triava against the TCK and also saw the issue. I agree that it is a bug in the TCK, and also fully support the proposed changes.
The other possible way would be to mandate that any "EntryProcessorException must be passed on directly". I would not like that, as it would be surprising and error-prone to offload the correct unwrapping to the invoke() caller. The caller should get the Exception as-is.
Just removed the idea to change the exception in the API for the EntreProcessor.process method:
That is not strictly binary compatible and might break things. We cannot fix the interface.
There are a couple of other places that specify exceptions such as
The TCK tests that an Exception is not wrapped by the implementation when it is already a
Re-Throwing an exception directly will lead to confusion if the code was run in another thread or on another JVM. In this case the stack trace is wrong and would not include the actual caller. IMHO cache implementations should consistently wrap exceptions, the stack trace of the wrapped exception must fit the actual calling context.
For a 1.1 MR I would suggest to relax the TCK tests, that implementations may be allowed to consistently wrap exceptions. Thoughts?
Wrap up of possible changes:
a) do nothing
b) Allow cache implementations to always wrap the exception, as the Spec says, but also allow the current behavior of not wrapping, if it is already a CacheException. This means that existing implementations don't need to change, but can do the agreed correct thing and always wrap.
c) enforce that cache implementations always wrap the thrown exception. Cache implementation need to change the behavior.
…s be wrapped, addresses jsr107/jsr107tck#85