4 ms·
Eh, I think this is a bit of a strawman. Yes, you can write obtuse Java code where you need to null check (or optional-unbox) everything. You can also write jav
by marginalia_nu 4y ago
Eh, I think this is a bit of a strawman. Yes, you can write obtuse Java code where you need to null check (or optional-unbox) everything. You can also write java code where every function has an integer return value that you need to check like in C, or any other weird and error-prone paradigm.
You can also just avoid returning nulls and not have this problem at all. I think unless you're dealing with code that was written close to 20 years ago, or was written by someone living under a rock for as long, nulls will rarely be a problem. Putting tons of effort into building strong compiler guarantees that prevents a problem that at best is hypothetical seems like more effort than it is worth.
- Larrikin 4y agoWith built in null safety, null becomes a useful result to pass around.
- marginalia_nu 4y agoI 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 agoA 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 agoNothing 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.
- mrkeen 4y agoUnfortunately not. Nulls are alive and well. Our teammates are putting them into our codebases as we speak.
- marginalia_nu 4y agoYou should consider talking to them about adopting 21st century coding conventions.
- mrkeen 4y agoIt's like an agile backlog. The stuff I want to correct grows much faster than what I have the social capital for. E.g. "being able to run your service locally and meaningfully" is something that's more important to me than no-nulls.
- marginalia_nu 4y agoIs it null really meaningful?