[
https://issues.apache.org/jira/browse/THRIFT-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13612206#comment-13612206
]
Eirik Sletteberg commented on THRIFT-1871:
------------------------------------------
I chose "nullable" because this (when I made the patch) was the first time I
had touched a parser generator, and I couldn't actually get it to use the
"optional" keyword, which would have been better. (So I chose "nullable" as a
synonym)
The way I see this could be implemented, preserving backwards compatibility, is:
1) Add the "optional" keyword for functions' return value.
2) Let generators/protocols/implementations ignore this keyword, pretending
it's not there by default. Functions are still allowed to return null.
3) If a generator wants to implement different behavior if no return value is
given (for example if no user is found), send null over the wire.
4) When a thrift client receives a null value from a function marked in the IDL
as optional, it should be returned as a "None" construct.
> Better null-safe handling
> -------------------------
>
> Key: THRIFT-1871
> URL: https://issues.apache.org/jira/browse/THRIFT-1871
> Project: Thrift
> Issue Type: Brainstorming
> Components: Compiler (General)
> Reporter: Eirik Sletteberg
> Attachments: Add_nullable_modifier_to_functions.patch
>
>
> Optional fields are not really handled well, especially in java clients.
> (NullPointerExceptions everywhere)
> Scrooge (Twitter's alternative Thrift compiler implementation) solves this
> problem by wrapping all optional fields in an Option<T> class. Could this be
> implemented in Thrift?
> As of today, services have no way of returning empty results; for example
> UserService {
> 1: User getUser(1: i32 id)
> }
> cannot return an empty user if the ID is not found.
> There are a few ways to solve this:
> UserService {
> 1: User getUser(1: i32 id) throws UserNotFoundException
> }
> -- or --
> UserService {
> 1: List<User> getUser(1: i32 id)
> }
> where an empty list is returned of no user is found, and a list containing
> one item is returned if a user is found.
> -- or --
> UserResult {
> 1: bool exists;
> 2: User user;
> }
> UserService {
> 1: UserResult getUser(1: i32 id)
> }
> I don't like any of them.
> One could solve this by letting the "optional" keyword apply to methods:
> UserService {
> 1: optional User getUser(1: i32 id)
> }
> or adding a new type to the IDL; the Option type:
> UserService {
> 1: Option<User> getUser(1: i32 id)
> }
> and then, like Scrooge does, generate code that wraps the optional fields in
> an "Option" type, which is null-safe.
> The Option type could also be used in structs:
> struct User {
> 1: i32 id;
> 2: string name;
> 3: optional string email;
> }
> -- or --
> struct User {
> 1: i32 id;
> 2: string name;
> 3: Option<string> email;
> }
> Either way, a null-safe Option wrapper would be used in the generated java
> code.
--
This message is automatically generated by JIRA.
If you think it was sent incorrectly, please contact your JIRA administrators
For more information on JIRA, see: http://www.atlassian.com/software/jira
