Summary
Dart has so far disallowed throwing null. If you try, that throws a NullThrowError instead.
With Null Safety, we disallow throwing nullable values entirely, and methods which accept thrown objects requires non-null arguments. This includes methods accepting async errors.
What is changing:
The interfaces of methods like Completer.completeError, Stream.addError or Future.error stop implicitly accepting null. They currently accept null and silently convert it to an async NullThrownError.
They will stop doing so, and will instead throw an Error synchronously if they receive a null error object.
Code accepting error handling functions will also change to only require a void Function(Object, StackTrace) in null-safe code, but that should not affect someone passing a void Function(Object?, StackTrace?) method.
Why is this changing?
Because in Null Safe code those parameters become non-nullable. Passing null is not allowed. Until we have full null safety (no non-Null Safe code left), null can still occur as an argument anyway, but we treat that consistently like the error that it is.
(Whether it throws a TypeError or an ArgumentError depends on how the testing code is written. That testing code will be removed when Dart stops supporting non-null-safe code).
Expected impact
Hopefully minimal. Since throwing null is already disallowed, and a null is not a useful error, code explicitly null as an error value is unlikely to be deliberate.
This change might catch some such errors, and those will need to figure out why they are using null as an error.
The workaround is simple: errorExpresson becomes (errorExpression) ?? NullThrownError().
Summary
Dart has so far disallowed throwing
null. If you try, that throws aNullThrowErrorinstead.With Null Safety, we disallow throwing nullable values entirely, and methods which accept thrown objects requires non-null arguments. This includes methods accepting async errors.
What is changing:
The interfaces of methods like
Completer.completeError,Stream.addErrororFuture.errorstop implicitly acceptingnull. They currently acceptnulland silently convert it to an asyncNullThrownError.They will stop doing so, and will instead throw an
Errorsynchronously if they receive anullerror object.Code accepting error handling functions will also change to only require a
void Function(Object, StackTrace)in null-safe code, but that should not affect someone passing avoid Function(Object?, StackTrace?)method.Why is this changing?
Because in Null Safe code those parameters become non-nullable. Passing
nullis not allowed. Until we have full null safety (no non-Null Safe code left),nullcan still occur as an argument anyway, but we treat that consistently like the error that it is.(Whether it throws a
TypeErroror anArgumentErrordepends on how the testing code is written. That testing code will be removed when Dart stops supporting non-null-safe code).Expected impact
Hopefully minimal. Since throwing
nullis already disallowed, and anullis not a useful error, code explicitlynullas an error value is unlikely to be deliberate.This change might catch some such errors, and those will need to figure out why they are using
nullas an error.The workaround is simple:
errorExpressonbecomes(errorExpression) ?? NullThrownError().