[
https://issues.apache.org/jira/browse/THRIFT-517?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=12868253#action_12868253
]
andrew zimmer commented on THRIFT-517:
--------------------------------------
Why not just append the throwable's getMessage() or even toString() in the
internal error text? I understand that this doesn't render the exception most
elegantly, but I think by not including any details at all the client is pretty
clueless. The debug process without any message to the client then results in
confusion and requires that someone on the server side line up log timestamps
with the operator on the client side.
In a web app, it makes sense that one doesn't barf the stack trace to the user.
But in this case I think you want to give as much detail as possible. Clients
can still trap the general "unexpected" exception differently, but having a bit
more detail in the logs would be hugely helpful for those of us on the server
side who have a slew of code that throws RuntimeExceptions that shouldn't be
turned into checked exceptions in Thrift.
Here's how I hand patch the generated code:
} catch (Throwable th) {
LOGGER.error("Internal error processing [method name here]", th);
TApplicationException x = new
TApplicationException(TApplicationException.INTERNAL_ERROR, "Internal error
processing [method name here: " + th.getMessage());
It's a simple change and I think it would give the client a lot of useful
information without breaking any exception models. It's just a log message,
after all :)
> TExceptions thrown by server result in cryptic error message on client -
> Tried to read 4 bytes, but only got 0 bytes
> --------------------------------------------------------------------------------------------------------------------
>
> Key: THRIFT-517
> URL: https://issues.apache.org/jira/browse/THRIFT-517
> Project: Thrift
> Issue Type: Bug
> Components: Compiler (Java), Library (Java)
> Reporter: Adrian Woodhead
>
> To reproduce:
> 1. Define a simple Thrift service method with no custom exceptions.
> 2. In server implementation of service method, throw a TException.
> 3. Generated code in client forces you to do try/catch TException around
> service call, do this, and output stack trace,
> The exception thrown by the server then results in this rather cryptic error
> message in the client:
> 26 22:32:44,931 INFO Caused by:
> org.apache.thrift.transport.TTransportException: Cannot read. Remote side has
> closed. Tried to read 4 bytes, but only got 0 bytes.
> 26 22:32:44,931 INFO at
> org.apache.thrift.transport.TTransport.readAll(TTransport.java:86)
> 26 22:32:44,931 INFO at
> org.apache.thrift.protocol.TBinaryProtocol.readAll(TBinaryProtocol.java:314)
> 26 22:32:44,931 INFO at
> org.apache.thrift.protocol.TBinaryProtocol.readI32(TBinaryProtocol.java:262)
> 26 22:32:44,931 INFO at
> org.apache.thrift.protocol.TBinaryProtocol.readMessageBegin(TBinaryProtocol.java:192)
> 26 22:32:44,931 INFO at
> fm.last.catalogue.api.TCatalogueAPI$Client.recv_getTrackById(TCatalogueAPI.java:249)
> It would be better if the client got the actual TException sent by the
> server, or at the very least a better error message indicating that an
> unexpected error occurred on the server (akin to an HTTP 500 message that
> most web servers use).
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
