[
https://issues.apache.org/jira/browse/THRIFT-3607?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel
]
Aki Sukegawa updated THRIFT-3607:
---------------------------------
Description:
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.
was:
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 unify the TProcessor behavior to catch-all, so that
servers never die on handler exceptions.
> Unify exception handling policy of TProcessor
> ---------------------------------------------
>
> Key: THRIFT-3607
> URL: https://issues.apache.org/jira/browse/THRIFT-3607
> Project: Thrift
> Issue Type: Improvement
> 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.4#6332)
