[
https://issues.apache.org/jira/browse/THRIFT-2157?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=14380383#comment-14380383
]
Iker Jimenez edited comment on THRIFT-2157 at 3/25/15 8:38 PM:
---------------------------------------------------------------
Hi [~jensg],
so I've looked into this a bit further. Only scratched the surface of it, so
allow for some imprecisions.
It looks like the way the Thrift Java API and
compiler/cpp/src/generate/t_java_generator.cc are written forces everything to
be a TBase type of object. Notice how, even though the snippet above doesn't
show it, msg is defined to be of type TBase (this is coming from
t_java_generator.cc).
[~dvdreddy] at THRIFT-2988 is spot on, there is one imprecission though, which
might make you reconsider his first proposal.
TBase is not a class but an interface, notice how custom exceptions are
actually generated as "extends TException implements TBase"
The code generation logic is written assuming that because custom exceptions do
implement TBase, then TApplicationException does too.
I do not see an easy way of changing the code generator to work around the fact
that TApplicationException doesn't implement TBase.
Since custom exceptions already implement TBase, I don't see any reason why
TApplicationException couldn't too. My proposal would go towards making
TApplicationException implement TBase, you wouldn't need to change the class
hierarchy this way and it would be backwards compatible.
Thanks.
was (Author: iker.jimenez):
Hi [~jensg],
so I've looked into this a bit further. Only scratched the surface of it, so
allow for some imprecissions.
It looks like the way the Thrift Java API and
compiler/cpp/src/generate/t_java_generator.cc are written forces everything to
be a TBase type of object. Notice how, even though the snippet above doesn't
show it, msg is defined to be of type TBase (this is coming from
t_java_generator.cc).
[~dvdreddy] at THRIFT-2988 is spot on, there is one imprecission though, which
might make you reconsider his first proposal.
TBase is not a class but an interface, notice how custom exceptions are
actually generated as "extends TException implements TBase"
The code generation logic is written assuming that because custom exceptions do
implement TBase, then TApplicationException does too.
I do not see an easy way of changing the code generator to work around the fact
that TApplicationException doesn't implement TBase.
Since custom exceptions already implement TBase, I don't see any reason why
TApplicationException couldn't too. My proposal would go towards making
TApplicationException implement TBase, you wouldn't need to change the class
hierarchy this way and it would be backwards compatible.
Thanks.
> generated code would cause ClassCastException
> ---------------------------------------------
>
> Key: THRIFT-2157
> URL: https://issues.apache.org/jira/browse/THRIFT-2157
> Project: Thrift
> Issue Type: Bug
> Components: Java - Compiler
> Affects Versions: 0.9.1
> Reporter: Dave Brosius
> Priority: Trivial
>
> Looking at the thrift generated code for cassandra, i'm seeing
> msg = (org.apache.thrift.TBase)new
> org.apache.thrift.TApplicationException(org.apache.thrift.TApplicationException.INTERNAL_ERROR,
> e.getMessage());
> as seen here
> https://git-wip-us.apache.org/repos/asf?p=cassandra.git;a=blob;f=interface/thrift/gen-java/org/apache/cassandra/thrift/Cassandra.java;h=837acfc0e964249fd62720420e8f1f85d966f1a3;hb=8f202895ab9e17c3d6bd4965924fd5f1ffc27f94#l6095
> i don't see how TApplicationException can be cast to TBase, and so i'd expect
> a ClassCastException there.
--
This message was sent by Atlassian JIRA
(v6.3.4#6332)
