[
https://issues.apache.org/jira/browse/THRIFT-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15958897#comment-15958897
]
James E. King, III commented on THRIFT-3607:
--------------------------------------------
I would also suggest caution on catch-all behavior. In C++ it would be better
to catch std::exception, and if a handler/implementation throws something not
derived from that, it isn't following the language rules well. Further, on
some platforms in C++ if you catch (...) you can actually catch seg faults
(seen this behavior on Windows) and that should be avoided too.
> Unify exception handling policy of TProcessor
> ---------------------------------------------
>
> Key: THRIFT-3607
> URL: https://issues.apache.org/jira/browse/THRIFT-3607
> Project: Thrift
> Issue Type: Improvement
> Components: Wish List
> Reporter: Aki Sukegawa
>
> A discussion in THRIFT-1805 uncovered inconsistent error handling behaviors
> of TProcessors across languages and releases.
> Most outstanding are Java sync and async processors as described there, but
> others are also subtly different in details.
> I propose unifying the TProcessor behavior by specifying mappings from
> "uncaught server handler exceptions" to "observable server behaviors" as
> follows:
> * TApplicationException -> send TApplicationException with the message and
> the type as thrown
> * TTransportException -> the connection is either already broken or newly
> broken
> * other exceptions -> send opaque TApplicationException(INTERNAL_ERROR)
> That way users can still arbitrarily disconnect the client by throwing
> TTransportException.
> (IMO ideally this should have been done by exposing "client context" object
> to the handler instead)
> The first one can be a bit controversial as it can be regarded as information
> leak.
> Also some may prefer unifying the TProcessor behavior to catch-all, so that
> servers never die on handler exceptions.
--
This message was sent by Atlassian JIRA
(v6.3.15#6346)
