Deprecate and stop using `NullThrownError`

[lrhn]

In (sound) null safe Dart, you cannot throw null. The throw operator expects a non-null operand. If you throw a dynamic-typed null value, you should get an error from the implicit downcast, not a NullThrownError. Same if you try to go through async operations or Error.throwWithStacktrace.

That means that we no longer need the NullThrownError error. Instead we should throw a TypeError for the invalid downcast from null to Object at points where you somehow manage to get a null into throw-error-position.

We should remove references to NullThrownError from the language specification, and we can then deprecate NullThrownError and remove it when ready, no sooner than when removing unsound null-safety mode.

[nshahan]

Some tests that contain expectations for a NullThrownError and need updating:

language/exception/exception_test
language_2/exception/exception_test

@lrhn
After the breaking change are we planning on having these test expectations diverge: TypeError with sound null safety, NullThrownError without? From the DDC perspective it seems easy enough to implement it in both at the same time and would allow for the error class to be removed from the SDK earlier.

[lrhn]

After the breaking changes, we should be at Dart 3.0.0, and there will no longer be any non-null-safety. (In the perfect world, at least).

So, yes, without the "without" part, we'll only throw TypeError (from a failed implicit downcast from dynamic to Object).

We should probably still have a few tests of code doing throw (null as dynamic);, to ensure that we do what we say that we do (throw TypeErrors), but any errors arising from, say, Completer.completeError, should never see a null because the parameter is typed as Object and we have sound null safety. We don't need to check what they do on a null, because they can't get one.

[nshahan]

Sounds good, thanks. I'll be waiting for the OK to land my cleanup.

I believe in targets building for the web there will be some settings were code will still be running in weak null safety in Dart 3.0. That said, as I understand it now this is a breaking change in Dart 3.0. The class will be removed and any code running with the Dart 3.0 SDK will need to cleanup all uses of the NullThrownError.

[lrhn]

Even if we leave in the ability to compile weak null-safety code in the web compilers for a short while after 3.0, for technical reasons, we still expect that code to have stopped using NullThrownError. That's a much smaller fix than a full migration, and it is not expected to be a problem.

[itsjustkevin]

@lrhn is there someone taking a look at this already? If not who would be the right person to tackle this removal?

[nshahan]

I have a CL ready that removes the use of the class from DDC that I created when I saw this issue get filed https://dart-review.googlesource.com/c/sdk/+/273281.

I haven't done any research into whether this is safe to land or not. A quick search in google3 looks like there are expectations for the error that ignore the deprecation message. It could be breaking for me to land it.

@lrhn Will the language/library team be cleaning up those uses?

[itsjustkevin]

@nshahan we have a CL cleaning up the uses of CyclicInitializationError, but no one covering the NullThrownError, so I've been looking around for an expert in this area.