You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by "ASF GitHub Bot (JIRA)" <ji...@apache.org> on 2017/02/10 03:58:42 UTC
[jira] [Commented] (THRIFT-1805) Thrift should not swallow ALL
exceptions
[ https://issues.apache.org/jira/browse/THRIFT-1805?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=15860648#comment-15860648 ]
ASF GitHub Bot commented on THRIFT-1805:
----------------------------------------
GitHub user ctubbsii opened a pull request:
https://github.com/apache/thrift/pull/1186
THRIFT-1805 Provide option for handling RTEs
Adds a Java option to the generator to generate code which lets Thrift
handle RuntimeExceptions from a service, and present them as
TApplicationException to the client.
This addresses a back-and-forth debate over the expected behavior of
this in Java services, and the resulting breakage, as described in
THRIFT-1805 and related issues, by making the behavior configurable.
Throwable types are not handled, because it is generally ill-advised to
handle Error types within a Java application. So, this only allows
configuration of handling RuntimeException.
This patch preserves current behavior as the default, and works with
previously generated code.
This patch does not affect AsyncProcessFunction exception handling.
Related JIRAs: THRIFT-378, THRIFT-1658, THRIFT-1805, THRIFT-3607
You can merge this pull request into a Git repository by running:
$ git pull https://github.com/ctubbsii/thrift handle-runtimeexceptions
Alternatively you can review and apply these changes as the patch at:
https://github.com/apache/thrift/pull/1186.patch
To close this pull request, make a commit to your master/trunk branch
with (at least) the following in the commit message:
This closes #1186
----
commit 48ee27b210edf2d92af2f5060820d77ca0898aff
Author: Christopher Tubbs <ct...@apache.org>
Date: 2017-02-10T03:32:00Z
THRIFT-1805 Provide option for handling RTEs
Adds a Java option to the generator to generate code which lets Thrift
handle RuntimeExceptions from a service, and present them as
TApplicationException to the client.
This addresses a back-and-forth debate over the expected behavior of
this in Java services, and the resulting breakage, as described in
THRIFT-1805 and related issues, by making the behavior configurable.
Throwable types are not handled, because it is generally ill-advised to
handle Error types within a Java application. So, this only allows
configuration of handling RuntimeException.
This patch preserves current behavior as the default, and works with
previously generated code.
This patch does not affect AsyncProcessFunction exception handling.
Related JIRAs: THRIFT-378, THRIFT-1658, THRIFT-1805, THRIFT-3607
----
> 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.15#6346)