You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@thrift.apache.org by Craig Artley <ca...@hotmail.com> on 2012/05/20 18:54:19 UTC

C++ and Java servers differ in their handling of standard exceptions

How come C++ and Java servers differ in their handling of standard exceptions?
The generated C++ service code catches std::exception and turns it into a TApplicationException and passes it back to the client.  In contrast, the generated Java service code does nothing like this. In particular, if a Java server encounters a RuntimeException, it is not handled.  The result is the client gets a cryptic TConnectionException with no indication of the problem.
Shouldn't the generated Java server code behave more like the C++ server?
You can see this in the code generated for the tutorial example.  If you look at the generated Calculator.cpp code for the C++ server, you will see that every process_* method includes catch blocks for std::exception. These catch blocks do the conversion to TApplicationException.  But when you look at the Java server code in Calculator.java, the getResult methods don't have any such catch blocks for RuntimeExceptions.
The upshot is that for Java servers to throw useful RuntimeExceptions like IllegalArgumentException requires the user to declare that every method throws a custom exception, then wrap every method implementation with boilerplate to catch RuntimeExceptions and translate them to the custom exception. This is onerous and error prone. Since the C++ server does it automatically, I think the Java server should as well.
Thrift-378 seems to address this issue. The conclusion is that it was fixed. However, it obviously is not.
  -craig 		 	   		  

AW: C++ and Java servers differ in their handling of standard exceptions

Posted by Roger Meier <ro...@bufferoverflow.ch>.
Hi Craig

Yes, there might be some differences on exception Handling.

Please help fixing or its java related subtasks
https://issues.apache.org/jira/browse/THRIFT-847

test/test.sh does cross language tests, see results:
https://builds.apache.org/view/S-Z/view/Thrift/job/Thrift/lastSuccessfulBuil
d/artifact/thrift/test/test.log

The test cases or required behavior for cross language tests is described at
test/ThriftTest.thrift

If you have a patch to  generate better exception handling for Java, just
create a new ticket.
We need better cross language interoperability!

Roger
;-r

> -----Ursprüngliche Nachricht-----
> Von: Craig Artley [mailto:cartley@hotmail.com]
> Gesendet: Sonntag, 20. Mai 2012 18:54
> An: dev@thrift.apache.org
> Betreff: C++ and Java servers differ in their handling of standard
exceptions
> 
> 
> How come C++ and Java servers differ in their handling of standard
> exceptions?
> The generated C++ service code catches std::exception and turns it into a
> TApplicationException and passes it back to the client.  In contrast, the
> generated Java service code does nothing like this. In particular, if a
Java
> server encounters a RuntimeException, it is not handled.  The result is
the
> client gets a cryptic TConnectionException with no indication of the
problem.
> Shouldn't the generated Java server code behave more like the C++ server?
> You can see this in the code generated for the tutorial example.  If you
look
> at the generated Calculator.cpp code for the C++ server, you will see that
> every process_* method includes catch blocks for std::exception. These
> catch blocks do the conversion to TApplicationException.  But when you
look
> at the Java server code in Calculator.java, the getResult methods don't
have
> any such catch blocks for RuntimeExceptions.
> The upshot is that for Java servers to throw useful RuntimeExceptions like
> IllegalArgumentException requires the user to declare that every method
> throws a custom exception, then wrap every method implementation with
> boilerplate to catch RuntimeExceptions and translate them to the custom
> exception. This is onerous and error prone. Since the C++ server does it
> automatically, I think the Java server should as well.
> Thrift-378 seems to address this issue. The conclusion is that it was
fixed.
> However, it obviously is not.
>   -craig