[jira] [Commented] (THRIFT-1871) Better null-safe handling

["Henrique Mendonca (JIRA)" <ji...@apache.org>]

    [ https://issues.apache.org/jira/browse/THRIFT-1871?page=com.atlassian.jira.plugin.system.issuetabpanels:comment-tabpanel&focusedCommentId=13624899#comment-13624899 ] 

Henrique Mendonca commented on THRIFT-1871:
-------------------------------------------

Hi Eirik, sorry for the delay again
I think your "scenario2" seems to be quite feasible for now.
Since it would involve only changes on the Java compiler, I'd advise you to open a separated ticket for that so the guys working with the Java library can also give their opinion.
Thank you for sharing your ideas.

ps: Can you not solve that with the normal primitive wrappers, e.g. java.lang.Integer ?? but I leave that to you guys to discuss and decide.
                
> 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