[
https://issues.apache.org/jira/browse/THRIFT-2935?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14271282#comment-14271282
]
Sergei Egorov commented on THRIFT-2935:
---------------------------------------
Yes, and as Java developer I totally disagree with THRIFT-1588. It causes a lot
of misunderstandings. Maybe, We can introduce some kind of TLogicException
extends Exception, and extends every generated exception from it. But use the
same exception for business logic and protocol (i.e. TTransportException
extends TException) is totally bad idea.
> Exceptions in Java code should not extends TException
> -----------------------------------------------------
>
> Key: THRIFT-2935
> URL: https://issues.apache.org/jira/browse/THRIFT-2935
> Project: Thrift
> Issue Type: Wish
> Components: Java - Compiler
> Affects Versions: 0.9.2
> Reporter: Sergei Egorov
> Labels: exception-handling, exceptions, java
>
> Exceptions in Java should not extend TException to avoid collisions on method
> signature for better IDE support. Currently, if service is throwing some
> thrift exception, i.e. TMyCustomException, it will have following signature:
> public void myMethod() throws TMyCustomException, TException {
> }
> But TMyCustomException is overlapped by TException,
> Now, if we will call this method in our code:
> client.myMethod();
> IDE will propose to generate try\catch with only 1 block:
> try {
> client.myMethod();
> } catch(TException e) {
> }
> Because TMyCustomException extends TException. If TMyCustomException will
> extends just Exception, than IDE will generate following code:
> try {
> client.myMethod();
> } catch(TMyCustomException e) {
> } catch(TException e) {
> }
> which is much better, because client caller will know about any custom(!)
> thrift exception in this method.
> Thanks!
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
