thrift-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Christopher Tubbs (JIRA)" <j...@apache.org>
Subject [jira] [Commented] (THRIFT-3607) Unify exception handling policy of TProcessor
Date Thu, 06 Apr 2017 17:45:42 GMT

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

Christopher Tubbs commented on THRIFT-3607:
-------------------------------------------

I agree with [~jking]'s comments about just throwing an opaque error, rather than sending
un-vetted error messages back to the client. For Java, I think it makes sense to catch, log,
and return TApplicationException for RuntimeException, but not for Error (or their common
parent, Throwable).

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

Mime
View raw message