[
https://issues.apache.org/jira/browse/THRIFT-4556?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=16781147#comment-16781147
]
Christopher Tubbs commented on THRIFT-4556:
-------------------------------------------
I really can't believe 026c9d032c4a298ecb9edbcdfb52590facb442f3 got merged
in... it flip-flopped the behavior (yet again)! Commit
5038466e5e57b17b881684bae0e541408aafac0e was *specifically added* to satisfy
both use cases... so the behavior in Thrift could stop flip-flopping on every
release, and actually remain stable. Yet, even with the flag present, a PR was
still accepted which flip-flopped the issue again. I'm sure one can appreciate
my frustration.
Seeing this, though, does help explain why my "ThriftBehaviorIT" I wrote to
ensure consistent behavior in my own application passed after I upgraded to
0.11.0, regardless of whether or not I set the flag to
handle_runtime_exceptions... since that flag was essentially being ignored in
0.11.0.
This code (the current JIRA) looks like it will also help to satisfy both
cases, and honestly, I like this fix better. It is, however, frustrating that
the slightly different implementation causes yet another breakage (because the
old flag no longer exists, and breaks my generator script), but that's easily
addressed.
I just hope that in 0.13.0, and future versions, the exception handling
behavior doesn't continue to flip-flop, as it has already done on half a dozen
releases. I think to avoid that, somebody needs to do a better job of triaging
PRs to see if there's a regression before merging them in.
Also, FWIW, the private void handleException method is now dead code, and can
be removed now. (The function it was serving was replaced by the last few lines
of the process function.)
> Optional rethrow of unhandled exceptions in java processor
> ----------------------------------------------------------
>
> Key: THRIFT-4556
> URL: https://issues.apache.org/jira/browse/THRIFT-4556
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler, Java - Library
> Affects Versions: 0.11.0
> Reporter: Nicolas Krog
> Assignee: James E. King III
> Priority: Major
> Fix For: 0.12.0
>
>
> Current behavior for Java processor is to do a minor logging of any unhandled
> exceptions and return to the client that an exception has happened.
> I would like to make it possible to rethrow the uncaught exceptions since we
> need that functionality in order to make 0.11.0+ version be compatible with
> our current code.
> The functionality we want is similar to the functionality of the commit
> 5038466e5e57b17b881684bae0e541408aafac0e, but that functionality was
> overwritten with the commit 026c9d032c4a298ecb9edbcdfb52590facb442f3 and left
> some code unused. We want to more or less reuse and adapt that unused code in
> order to make it possible for the user to choose whether uncaught exceptions
> should be re-thrown.
> More specifically:
> The command here, implemented with 5038..., made it possible for the user to
> specify whether a RuntimeException should be handled and returned to the
> client.
> $ thrift --gen java:handle_runtime_exceptions someThriftFile.thrift
> That flag is now of no use, because of the changes made in 026c9...
> We want to be able to do
> $ thrift --gen java:rethrowUncaughtExceptions someThriftFile.thrift
> Thus, making the java processor rethrow the exception and propagating it
> upwards.
>
--
This message was sent by Atlassian JIRA
(v7.6.3#76005)
