3 ms·

With built in null safety, null becomes a useful result to pass around.

• marginalia_nu 4y ago
  I think it's still probably a bad pattern to sometimes return a useful value through the same channel, whether through nulls or something else.
  • Larrikin 4y ago
    A simple example would be going through a rest response. If a value is present the text should display, if it isn't return null. Passing back a blank string would be the bad pattern.
    • marginalia_nu 4y ago
      > Passing back a blank string would be the bad pattern. That would actually be idiomatic Java behavior. But with REST, I think you should return different status codes and different types entirely if you're returning an error. Not try to communicate through the presence of absence of fields. You should definitely not return half-complete representations when something half-worked. Either it's complete and guaranteed to be fully populated, or it's not returned at all. e.g. HTTP 200: { "message": "hi mom!" } HTTP 404: { "error": "you came to the wrong neighborhood!" }
  • Clamchop 4y ago
    Nothing is a useful and meaningful result in a lot of cases. This is essentially a degenerate case of a discriminated union. There are other choices that can be used to the same effect, such as exceptions or sealed classes. Of course, you can still use Optional<T>. But with null safety, a nullable return type is often most elegant and it's idiomatic in Kotlin.