[jira] [Commented] (THRIFT-2975) Graceful handing of unexpected errors

["ASF GitHub Bot (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-2975?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14355781#comment-14355781 ] 

ASF GitHub Bot commented on THRIFT-2975:
----------------------------------------

Github user abhinav commented on the pull request:

    https://github.com/apache/thrift/pull/370#issuecomment-78155293
  
    This needs to log the actual exceptions before throwing TApplicationException to the clients and the clients need control of where the exceptions are logged. The current design doesn't cover that. Abandoning this diff to evaluate whether that's possible.


> Graceful handing of unexpected errors
> -------------------------------------
>
>                 Key: THRIFT-2975
>                 URL: https://issues.apache.org/jira/browse/THRIFT-2975
>             Project: Thrift
>          Issue Type: Improvement
>          Components: Python - Compiler
>    Affects Versions: 0.9.2
>            Reporter: Abhinav Gupta
>
> Currently, the Python compiler generate {{Processor.process_*}} methods that look something like,
> {code}
> def process_myMethod(...):
>   myArg = ...
>   try:
>     result.success = self._handler.myMethod(myArg)
>   except ExpectedException, e:
>     result.exc = ...
> {code}
> 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,
> {code}
> 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
> {code}
> 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.



--
This message was sent by Atlassian JIRA
(v6.3.4#6332)