3 ms·
Oh I didn't explain myself correctly. I've got nothing against the example in the blog post. What I mean is that no matter if Java or Kotlin makes guarantees
by TacticalCoder 4y ago
Oh I didn't explain myself correctly. I've got nothing against the example in the blog post. What I mean is that no matter if Java or Kotlin makes guarantees about null safety, invariability and the type of the object returned, in the end you still have to deal with the glorified GOTO statements that exceptions are.
- CrimsonRain 4y agoI like Java but being able to tell at compile time that don't allow null on something no matter what, gives you a lot of advantage (and some disadvantage if you design wrong). Exceptions are not necessary in this case as null safety can not be isolated (unless you choose it). It is either everywhere or nowhere or you force an arbitrary line by telling something not-nullable when it can be (not a good idea). A good example is the state Dart is in right now. Almost everything has been transformed to null-safety including most of the community packages and it works really nicely.
- kaba0 4y agoThey are the same thing as returning a sum type, just your goto hides in an if statement in that case you explicitly have to write out one way or another.