grpc-java: StatusException and StatusRuntimeException not serializable

StatusException and StatusRuntimeException are not serializable due to containing a Status object (which makes no attempt to be serializable) with no special handling.

Here’s a snippet from the exception that arises:

... snip ...
Caused by: java.io.NotSerializableException: io.grpc.Status
    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1184)
    at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
    at java.io.ObjectOutputStream.writeSerialData(ObjectOutputStream.java:1509)
    at java.io.ObjectOutputStream.writeOrdinaryObject(ObjectOutputStream.java:1432)
    at java.io.ObjectOutputStream.writeObject0(ObjectOutputStream.java:1178)
    at java.io.ObjectOutputStream.defaultWriteFields(ObjectOutputStream.java:1548)
    at java.io.ObjectOutputStream.defaultWriteObject(ObjectOutputStream.java:441)
    at java.lang.Throwable.writeObject(Throwable.java:985)
    at sun.reflect.GeneratedMethodAccessor129.invoke(Unknown Source)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    ... snip ...

Our use case is an RMI-like API to make calls to a server process which is then making gRPC calls. In this case an operation failed and then things go really wrong because we can’t see the root problem since the real exception can’t be serialized.

I think to be a “good citizen” the Status*Exceptions should be serializable so it would seem that either:

Status should also be
The status should be pulled apart and the pieces stored in the exception classes
Special serialization routines should be put in place to pull the Status apart on write and put them back together on read

If you know which approach you’d like to take, I’d be happy to implement it.

About this issue

Original URL
State: open
Created 8 years ago
Reactions: 6
Comments: 20 (11 by maintainers)

Most upvoted comments

Status is not Serializable and is unlikely to ever be. SE and SRE solely exist to extend Exception, and convert a Status into an exception.

Nor should it be. Effective Java #75: you should use a custom serialized form anyway. You can easily encode the Status into the official form you want during serialization and I would highly recommend that.

You have to show that making SE and SRE Serializable is generally useful (and not just useful to you). You have to show that it won’t complicate the API for marshalling Status (having two ways of doing something complicates the API). You also have to show that if we did make it serializable, we would not run into API compatibility problems when we wish to modify the internals of those classes. We are on the hook for ever if we do.

Somehow this has become viewed as a personal request. They are already Serializable. I did not request it… they are by necessity: screen_shot_2017-01-17_at_7_11_34_pm

I argue this is a bug, not a feature request. It’s like throwing an exception when toString() is called. It’s part of the object contract and is something that shouldn’t cause an explosion. You could omit data from the serialized form, but exploding isn’t right.

Anyway, I’ll bow out now and defer to others…

robeden on Jan 18, 2017