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

["Jens Geyer (JIRA)" <ji...@apache.org>]

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

Jens Geyer edited comment on THRIFT-2975 at 2/3/15 10:59 PM:
-------------------------------------------------------------

{quote}
due to a bug, for example
{quote}

IMHO that's the most common case. The usual solution is to wrap everything into a try/catch statement, then throwing one of the exceptions defined in the IDL at the service function. If the one is considered security relevant, then the other is as well, because the only difference is who writes the code - the Thrift compiler or the developer. 

For services used only internally cutting off the connection is just bad and comes without any of the benefits. IMHO.

$0,02


was (Author: jensg):
{quote}
due to a bug, for example
{quote}

IMHO that's the most common case. The usual solution is to wrap everything into a try/catch statement, then throwing one of the exceptions defined in the IDL at the service function. If the one is considered security relevant, then the other is as well, because the only difference is who writes the code - the Thrift compiler or the developer.

$0,02

> 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)