Eirik Sletteberg created THRIFT-1871:
----------------------------------------
Summary: 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
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
