I'd rather prefer to have these exceptions handled by the callee, if problem with serialization awareness is needed by the lib clients, however i'm not sure if this behaviour is somehow implied by how tchannel should function
p.s. by doing this, the actual tchannel calls would not get answered, since the responses will not get published. This will result in timeouts on the tchannel callers side
The code now logs the exception (instead of printing the stack trace to stdout).
Changing it to throw it instead does make sense yet might be a breaking change.
Hi, I just came to notice that the current implementation of the
ThriftSerializer.encodeBody()
will swallow any exceptions thrown by the validation of the thrift response and only print the exception stack trace: https://github.com/uber/tchannel-java/blob/5f18d0645750edf84168b3974bf8f804fb923039/tchannel-core/src/main/java/com/uber/tchannel/messages/ThriftSerializer.java#L88-L97I'd rather prefer to have these exceptions handled by the callee, if problem with serialization awareness is needed by the lib clients, however i'm not sure if this behaviour is somehow implied by how tchannel should function
p.s. by doing this, the actual tchannel calls would not get answered, since the responses will not get published. This will result in timeouts on the tchannel callers side
thanks atanas