[
https://issues.apache.org/jira/browse/THRIFT-5823?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=17898788#comment-17898788
]
Jens Geyer commented on THRIFT-5823:
------------------------------------
This is from the
[whitepaper|https://thrift.apache.org/static/files/thrift-20070401.pdf] (the
only real spec we have):
{quote}2.4 Exceptions
Exceptions are syntactically and functionally equivalent to structs except that
they are declared using the exception keyword instead of the struct keyword.
The generated objects inherit from an exception base class as appropriate in
each target programming language,
in order to seamlessly integrate with native exception handling in any given
language. Again, the design emphasis is on making the code
familiar to the application developer.
{quote}
Given the (rather incomplete and raw) IDL syntax alone both on the web site and
in {{{}thriftl.ll{}}}, and ignoring anything else, it is not fully clear what
the intention was. But if we also look at the paragraph above and at the test
cases that were originally given, at least to me it looks pretty much as if
nobody had that such a use case in mind even remotely. Particularly the
emphasized special case "inherit from an exception base class [...] to
seamlessly integrate with native exception handling in any given language"
would have implied a strong need for such test cases, because it is not only
obvious, but +expected+ that exceptions and structs are different beasts in
most (if not all) languages, thus requiring special care and tests. But such
tests never existed (not counting the two deeply buried under lib/go that were
added much later).
So from the overall picture I think it is fair to say that the original design
did even remotely have in mind to really use exceptions where structs are
allowed, hence the part "syntactically and functionally equivalent to structs"
above should most likely be interpreted as "regarding wire representation of
the data". I agree there's a lot of interpretation in this, but I think we can
safely summarize it as: "That's really not how it was meant to be used at all."
On the other hand, of course, the WP like any other spec is not a sacred holy
document and surely can evolve and change.
So what we could do is to make in an official feature and allow that an
exception could be treated like any struct data type, only with the additional
feature that it can be thrown and caught. That would require to make sure that
all target languages understand that conceptual change (which they do not as it
is now - whole reason why I came across this) and thus have a dedicated test
case for it in the test suite, similar to what I we did with the uuid data
type. That's where it should start IMHO.
Last not least, we should have a separate ticket for it.
----
PS: TBH I find the term "partial error" quite irritating. What is a partial
error again? It failed, but only a bit? Could that still be an idempotent
operation? I gave you 10 bookings about 100 dollar each and got a partial error
"some money could not be send to your bank account". Now what do I do with that
information? Can I throw and catch that error? Or better not, because at least
I got some money, just not all of it? And which of the bookings did fail? How
money do I have now? Hard to tell ...
> Fix illegal uses of exceptions as normal struct type
> ----------------------------------------------------
>
> Key: THRIFT-5823
> URL: https://issues.apache.org/jira/browse/THRIFT-5823
> Project: Thrift
> Issue Type: Bug
> Components: Compiler (General)
> Reporter: Jens Geyer
> Assignee: Jens Geyer
> Priority: Major
> Fix For: 0.22.0
>
> Attachments: THRIFT-5823.thrift
>
> Time Spent: 1h
> Remaining Estimate: 0h
>
> Fix illegal uses of exvceptions as normal struct type, which it really isn't.
> Applies to a number of test IDL files and various tickets.
--
This message was sent by Atlassian Jira
(v8.20.10#820010)
