Null is considered bad, because of nullcheck. My question is, what other way there is, that would have replaced this null problem? How could that have been avoided?
Software Engineering Stack Exchange is a question and answer site for professionals, academics, and students working within the systems development life cycle. It only takes a minute to sign up.
Sign up to join this community
Maybe
monad orOption
type is that the type system requires you to check whether the value is null. Ifx
is an instance of a nullable type, Java allows you to dox.foo()
which can throw a NullPointerException. IfmaybeX
is an Option,maybeX.foo()
won't compile. In manyOption
implementations you could domaybeX.get().foo()
which is equivalent to not checking for a null pointer, but there are stricter variants where you have to have to supply code paths for both alternatives. E.g. in Scala:val y = maybeX getOrElse { throw SomeException() } + 2
– amon Oct 3 '15 at 12:33List<T>
. The backing store needs to be an array with more elements than the list has items, and there's really no sensible value that can be placed in the unused slots. One could have code generation generate run-time null checks for non-nullable generic types and omit such checks for nullable ones, but that would impose added costs at run-time without necessarily providing any useful safety improvement. – supercat Oct 29 '15 at 15:13