Details
-
Improvement
-
Status: Open
-
Major
-
Resolution: Unresolved
-
0.9.2
-
None
-
None
Description
Currently, the Python compiler generate Processor.process_* methods that look something like,
def process_myMethod(...):
myArg = ...
try:
result.success = self._handler.myMethod(myArg)
except ExpectedException, e:
result.exc = ...
If handler.myMethod throws an exception that was not defined in the service interface (due to a bug, for example), the client connection is terminated without any extra information being sent down. This is unideal because the client dos not know whether the issue was a networking error or a server-side problem.
A possibly better behavior would be,
def process_myMethod(...):
myArg = ...
try:
self._handler.myMethod(myArg)
except ExpectedException, e:
...
except Exception:
exc = TApplicationException(INTERNAL_ERROR)
# write exc to output protocol as an exception
The generated clients already expect TApplicationException in the response and know how to parse and handle them, so this won't require any change on the client side.
Note that this will leave the connection open for further requests. My understanding is that there are some security concerns around that. So perhaps the behavior could be that process_* throws a TApplicationException and Processor.process catches it, sends it to the client and terminates the connection.
Attachments
Issue Links
- relates to
-
THRIFT-2908 Limited use Thrift::ApplicationException in Ruby
- Open
-
THRIFT-2860 Delphi server closes connection on unexpected exceptions
- Closed