StatusException and StatusRuntimeException not serializable
See original GitHub issueStatusException 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.
Issue Analytics
- State:
- Created 7 years ago
- Reactions:5
- Comments:17 (10 by maintainers)
Top Results From Across the Web
StatusException (grpc-all 1.51.0 API)
Status in Exception form, for propagating Status information via exceptions. This is semantically equivalent to StatusRuntimeException , except for usage in ...
Read more >java - gRpc, client getting io.grpc.StatusRuntimeException ...
1 and protobuf 3.11. Everything compiles and starts up just fine, when the client makes a call to the server, the server receives...
Read more >StatusRuntimeException is threw instead of StatusException ...
I just specified the exception type in place (1) as I want to the server side to throw a checkable exception, but the...
Read more >Error Handling in gRPC - Baeldung
In general, we should not include errors in the response payload. ... setCommodityName("Commodity5") .build(); StatusRuntimeException thrown ...
Read more >io.grpc.protobuf.StatusProto java code examples - Tabnine
getCode()} is not a valid * gRPC status code. * @since 1.3.0 */ public static StatusRuntimeException toStatusRuntimeException(com.google.rpc.
Read more >Top Related Medium Post
No results found
Top Related StackOverflow Question
No results found
Troubleshoot Live Code
Lightrun enables developers to add logs, metrics and snapshots to live code - no restarts or redeploys required.
Start FreeTop Related Reddit Thread
No results found
Top Related Hackernoon Post
No results found
Top Related Tweet
No results found
Top Related Dev.to Post
No results found
Top Related Hashnode Post
No results found
Top GitHub Comments
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.
Somehow this has become viewed as a personal request. They are already Serializable. I did not request it… they are by necessity:
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…
@ericmandm, let’s move your discussion to https://github.com/grpc/grpc-java/issues/6853