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

Aki Sukegawa commented on THRIFT-1805:
--------------------------------------

Should have noted here: I've proposed a policy for TProcessor exception 
handling in THRIFT-3607 .
If everyone is happy with it, the plan is to update cross language tests, after 
that we have a consensus on Java sync processor here.

The current behavior does give more control to users if (and only if) they're 
implementing custom servers.
To me, this extra control should be added on top of "standard" behavior if at 
all, that is to send TApplicationException back.
An example is TTransport::getOrigin method in C++ that gets clients' address.
It opens a possibility for users' applications to, e.g., accumulate statistics 
on which client causes errors and prohibit them using external proxy etc.
So the bottom line is that, in my opinion, we can remove the current behavior 
but be open to alternative suggestions that does not modify the default 
behavior.

> Thrift should not swallow ALL exceptions
> ----------------------------------------
>
>                 Key: THRIFT-1805
>                 URL: https://issues.apache.org/jira/browse/THRIFT-1805
>             Project: Thrift
>          Issue Type: Bug
>          Components: Java - Compiler, Java - Library
>    Affects Versions: 0.9
>            Reporter: Diwaker Gupta
>            Assignee: Diwaker Gupta
>         Attachments: THRIFT-1805.patch
>
>
> In Thrift 0.8.0, Thrift generated Java code did not swallow application 
> exceptions. As a result of THRIFT-1658, this behavior changed in 0.9.0 and 
> now the generated code swallows ALL application exceptions (via 
> ProcessFunction). Apparently this was the behavior in Thrift 0.6.0 and while 
> I see the rationale, it is breaking our applications.
> Our code relies on the fact that exceptions can propagate outside of Thrift 
> for certain things (e.g., to aggressively drop connections for clients that 
> send invalid/malformed requests). ProcessFunction makes it near impossible to 
> do this -- not only does it swallow the exception, it also loses all 
> information about the original exception and just writes out a generic 
> TApplicationException.
> IMO ProcessFunction should only catch TException. If the application code 
> wants to use other exceptions for some reason (in particular, Errors and 
> RuntimeExceptions), Thrift shouldn't prevent that.



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

Reply via email to