Details
-
Brainstorming
-
Status: Open
-
Major
-
Resolution: Unresolved
-
None
-
None
-
None
Description
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.
Attachments
Attachments
Issue Links
- relates to
-
THRIFT-1909 Java: Add compiler flag to use the "option pattern" for optional fields
- Closed