It becomes a significant effort to backtrace whether a variable could be null or not, and it may make some of us anxious to change anything at all. This works for small familiar projects, but breaks down when facing a larger code base. Without a proper way to convey (non-)nullability, programmers are required to always mentally carry the nullability information in their head. The bottom line is, you have to treat optional attributes differently than mandatory ones. notify and apologize to the user and inform your programmers (or yourself) that they (or you) screwed up. You should have some global error handling in place anyway to deal with uncaught exceptions in a reasonable way, e.g. You could write a log message or throw another exception in the else branch, but at this point, you’re better of just dereferencing your variable and possibly letting a NullPointerException happen. Writing an if-not-null check is easy, but the problem is the (implicit) else that comes with it. You may be tempted to write, just to be safe, null-checks anyway, but it would not serve you well. For example, when your customer may or may not have an email, you will have defined how to contact him in either case.įor mandatory attributes, on the other hand, we generally don’t define what should happen if the value is absent (because, well, that should never happen). Not knowing whether a variable can be null or not is.įrom a design perspective, when you have an optional attribute, you will have specified how to deal with its absence. The problem in an object-oriented language like Java is that all types are nullable and that there is no native way to express that a variable is never null. While null references have been called a “billion-dollar mistake”, null to represent absence of value is an important concept. In this article we will look at one of the main reasons for using Kotlin over Java: Null Safety.
0 kommentar(er)
