For the latest Dart news, visit our new blog at https://medium.com/dartlang .
If you have the NullPointerException in your code, its time get rid of it.
Lasse Nielsen writes:
The ugly duckling of exceptions, the NullPointerException, has been removed.
It had numerous problems. The two most immediate ones were that there wasn't a pointer, and it wasn't an exception. And it was causing confusion, most visibly by its being used inconsistently:
As always, we invite you to join our Dart mailing list, ask questions on Stack Overflow, or file feature requests on dartbug.com.
- It should, by the spec, be a subclass of NoSuchMethodError (and hence be an error), and be thrown by Null.noSuchMethod.
- It should also be thrown if you tried to throw the null object - which matched badly with being a NoSuchMethodError.
- And it was being thrown by methods that couldn't handle a null argument value. This was Java style, because it allowed you to skip a test in Java and just use the object and still get the same exception.
Without NullPointerException, those three cases now need to be handled independently:
- Accessing a missing member on null will throw a NoSuchMethodError, just like on any other object. The receiver will be null, so we can format the error message specially if we want it.
- Throwing the null object now throws the new NullThrownError.
- Invalid arguments should be reported by an ArgumentError, even if the invalid argument is null.
In Dart, null is not (that) special. It's just an object like any other. The things that make it special are basically:
- Type assertions always accept it - that's what "nullable types" means in Dart.
- It's returned automatically by functions without a return (or with a "return;" statement).
- You can't extend Null - and wouldn't be allowed to, even if the type was visible.
- You can't throw it (which is just a choice, not something inherently required by the Dart object model).
Change landed in r15136.