Question:
Should we avoid return a null collections? I’m see a at least 4 problems at one class, when we return null list, and without checking using them. E.g., see api: org.openmrs.module.ModuleFactory#getModulesInStartupOrder
Sorry for my English
I think this is a great suggestion. I wonder if sonarqube could be configured to help us identify and avoid this antipattern.
One exception I can think of is for patient allergies, where null and an empty list have different meanings (i.e., null means we don’t know any information about the patient’s allergies and an empty list means we know the patient does not have any allergies).
But in the far more common case where null and empty list are functionally equivalent, there’s no reason to return null.
May be we can use Optional<List<Allergy>> for patient allergies.
Or we can use OpenmrsUtil.Allergies which contains allergyStatus.
Optional would be nice (a kinder way of returning null).
I’m not a fan of the allergyStatus implementation. It feels clunky having a separate property to tell you whether another property is null, empty, or not empty (i.e., introducing the chance the two properties could get out of sync).