Records =?utf-8?Q?=E2=80=94_?=Dealing with nullable values
Arash Shahkar
arash.shahkar at gmail.com
Sat Dec 14 22:01:09 UTC 2019
Hi,
I’ve been using Lombok for quite a while now to automatically generate boilerplate code for "data carrier" classes. However, a pattern I really like and have found to work very well is to verify non-nullity of all the fields that must not be null, and return an Optional<Field> from the accessor of a field if it’s allowed to have a null value. Consider:
@lombok.Value
class Person {
String name;
Gender gender;
Person(String name, Gender gender) { … } // customize the constructor, verifying that name is defined and valid
Optional<Gender> getGender() { // customize the accessor for gender, to make sure calling code deals with the possibility of gender being null
return ofNullable(gender);
}
}
Doing a similar thing with records is not possible, due to the fact that the accessor for gender has to exactly return a Gender. With the current specification for records, the only option is to do:
record Person(String name, Optional<Gender> gender) {
…
}
Is this considered good practice? Do you suggest any alternatives?
More information about the amber-dev
mailing list