Dit is meer een conceptuele vraag: Indien een method een string terug geeft, zou dan een default value null beter zijn dan een default value "empty string"?
We hebben hier op kantoor een discussie waarbij er eigenlijk 3 kampen zijn:
• Null als default value
• Empty string als default value
• Optional<String> als return value
Ik ben zelf van mening dat null betekent "onbekend" of "niet aanwezig" en dus zou moeten dienen als default return value.
Wat use-cases, waar naar mijn mening het volgende van toepassing is:
• Street-class: List<House> getHouses() - Zou een lege list moeten teruggeven als er geen huizen in die straat staan (en dus niet null en al zeker geen Optional<List<House>>)
• House-class: String getNumberSuffix() - Zou een suffix terug moeten geven, of anders null (niet van toepassing)
...
Een van de argumenten om een lege string terug te geven is volgens een aantal ontwikkelaars dat er minder kansen op fouten bestaan. Ik moet dan meteen denken aan de gevallen waar er niet een string-object wordt teruggegeven, maar een ander concreet object. Ik ga ook niet een Street object instantieren waarbij ik dan geen enkele field assign, om zo te bepalen dat dit 'null' betekent.
Ik heb al wat discussies gevonden op sites als Stackoverflow, maar het lijkt erop dat er geen eenduidig antwoord is, en Stackoverflow is blijkbaar ook niet de website waar een dergelijke discussie moet plaatsvinden:
https://stackoverflow.com...een-null-and-empty-string
https://stackoverflow.com...ull-and-empty-java-string
Ikzelf vind dit wel een leuke manier om empty string vs null te omschrijven:

Maar dat geeft eigenlijk nog steeds niet een richtlijn om de return value van een method te bepalen in alle gevallen.
We hebben hier op kantoor een discussie waarbij er eigenlijk 3 kampen zijn:
• Null als default value
• Empty string als default value
• Optional<String> als return value
Ik ben zelf van mening dat null betekent "onbekend" of "niet aanwezig" en dus zou moeten dienen als default return value.
Wat use-cases, waar naar mijn mening het volgende van toepassing is:
• Street-class: List<House> getHouses() - Zou een lege list moeten teruggeven als er geen huizen in die straat staan (en dus niet null en al zeker geen Optional<List<House>>)
• House-class: String getNumberSuffix() - Zou een suffix terug moeten geven, of anders null (niet van toepassing)
...
Een van de argumenten om een lege string terug te geven is volgens een aantal ontwikkelaars dat er minder kansen op fouten bestaan. Ik moet dan meteen denken aan de gevallen waar er niet een string-object wordt teruggegeven, maar een ander concreet object. Ik ga ook niet een Street object instantieren waarbij ik dan geen enkele field assign, om zo te bepalen dat dit 'null' betekent.
Ik heb al wat discussies gevonden op sites als Stackoverflow, maar het lijkt erop dat er geen eenduidig antwoord is, en Stackoverflow is blijkbaar ook niet de website waar een dergelijke discussie moet plaatsvinden:
https://stackoverflow.com...een-null-and-empty-string
https://stackoverflow.com...ull-and-empty-java-string
Ikzelf vind dit wel een leuke manier om empty string vs null te omschrijven:

Maar dat geeft eigenlijk nog steeds niet een richtlijn om de return value van een method te bepalen in alle gevallen.
[ Voor 40% gewijzigd door Tanuki op 18-04-2018 15:57 ]
PV: Growatt MOD5000TL3-XH + 5720wp, WPB: Atlantic Explorer v4 270LC, L/L: MHI SCM 125ZM-S + SRK 50ZS-W + 2x SRK 25ZS-W + SRK 20ZS-W Modbus kWh meter nodig?