[Breaking change request] Make TypeError not extend AssertionError

[lrhn]

Change:
We will make the platform TypeError class not extend/implement the AssertionError class.
That will also make it not inherit the message getter.

Reason for Change:
It is a legacy hold-over from Dart 1 that type errors (thrown by failing type annotations) are assertion errors (thrown by failed assertions in debug mode), because in Dart 1 type annotations were only checked in debug mode.

When we added the message operand to assert statements, we also added a message field to AssertionError. Then TypeError inherited that field, even though it had no need for it.

We plan to change which operations throw TypeError and CastError (most likely by combining the two and only have one error type), and that would then cause cast errors to also be assertion errors. So, before moving forward with any other error changes, we want to detach TypeError from AssertionError.

An alternative would be to simply deprecate TypeError and just use CastError for everything, but TypeError has the better name for being a general "not the type expected" error because Dart doesn't/won't have implicit casts.

Expected Impact:
You should generally not be catching errors, and if you do, it should be for generic handling like logging. Your code should not depend on which particular Error is thrown.

That doesn't hold for test code, where you very often do want to check that the error that occurs is the one that you expect.
If such code conflates TypeError and AssertionError by only expecting an AssertionError for code which triggers an assert in debug (assertions enabled) mode, but a type error in production mode when a wrong value gets past the disabled assertion, then that test will start failing when a TypeError occurs.
The Dart SDK itself has tests like this.

However, the impact is expected to almost exclusively affect tests, not production code, which gives the affected developers time to fix the tests.

Mitigating the Impact:
If your code starts failing because you expect an AssertionError and get a TypeError, then start expecting a TypeError.

Look at all places where you have try { ... } on AssertionError { ... } (remembering that catching a specific Error is discouraged in general, so there hopefully won't be many cases of this), and
consider whether it needs to handle TypeError instead or as well.

Look at places where your tests do expect(..., throwsAssertionError) and consider whether it should catch TypeError instead or as well.

If you have code which uses the message field of TypeError, then that will start failing, and it should stop doing so now. The message was a fixed text in the VM implementation, so it wasn't particularly useful.

[franklinyow]

cc @Hixie @matanlurey @dgrove for review and approval.

[matanlurey]

Seems fine

[vsmenon]

@lrhn - when we unfork, developers will start seeing CastError in a few places where they used to see TypeError, right?

If so, shall we combine both your bullets here:

dart-lang/language#787 (comment)

into this breaking change?

Otherwise, LGTM.

[Hixie]

There's logic in Flutter (at runtime in release builds) that specifically looks for AssertionError in some cases, but I doubt it'll be affected by this, so LGTM.

[franklinyow]

Approved

[lrhn]

@vsmenon Would it be easier to combine the two changes (TypeError is! AssertionError, CastError is TypeError) in one change than do them as two changes?

My guess is that the error situations are independent of each other, so there will be no work saved by combining them, it will just be a bigger chunk of work.

There might be a few cases where a test is changed from is AssertionError to is TypeError as part of the first change, and that check then starts catching CastError as well with the second change. I don't expect it to happen much, if at all.

[lrhn]

CL: https://dart-review.googlesource.com/c/sdk/+/136129

[vsmenon]

@lrhn @franklinyow - I'm fine either way. LGTM.