Skip to content
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

NotSerializableException with AssumptionViolatedException #1192

Closed
phoenix384 opened this issue Aug 21, 2015 · 4 comments
Closed

NotSerializableException with AssumptionViolatedException #1192

phoenix384 opened this issue Aug 21, 2015 · 4 comments

Comments

@phoenix384
Copy link

For example try to serialize the Exception thrown by
assumeNotNull(null, null);

Causes:
java.io.NotSerializableException: org.hamcrest.core.Every

org.junit.internal.AssumptionViolatedException is serializable because RuntimeException is. But the Matcher field is not serializable.

@schauder
Copy link

While I agree this is awkward, I'd be interested in why you are trying to serialize the exception.

@kcooney
Copy link
Member

kcooney commented Aug 22, 2015

I suspect an IDE or build tool is serializing the exception as part of its reporting mechanism.

Unfortunately, I think any fix would break serialization compatibility even for cases where a matcher isn't passed in. We could fix it in JUnit5, and accept that some tools will be broken until they update their dependencies...

Edit: actually, making the fMarcher field transient might not break serialization compatibility (except in cases where the matcher is serializable).

@phoenix384
Copy link
Author

Yes the test results are collected and saved for reporting purposes. A report mail is generated from the saved results. I could change the code that serializes the results to not serializing the exception but serializing only the exception message since I only need this message later on.
But I felt I should file an issue on that.

I don't know why the exception saves the matcher to generate the message every time it is needed. Maybe this behaviour is needed. But if not, wouldn't it be possible to generate the message in the constructor and throw away the matcher?

@kcooney
Copy link
Member

kcooney commented Aug 23, 2015

@phoenix384 saving the message in the constructor would be possible, but if we did that IDEs and build tools compiled with older versions of JUnit wouldn't work with newer versions of JUnit.

If marking the field as transient breaks serialization compatibility, we could write our own serialization code that always writes null for this field.

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

No branches or pull requests

3 participants