Consider adding `isTypeError` and possibly deprecating `isCastError`?

[leafpetersen]

CastError is deprecated and all implementations will start throwing an implementation object that implements TypeError instead. Consider adding a matcher isTypeError, and possibly deprecating isCastError as well?

[natebosch]

We want to move away from owning all these is*Error matchers, so I think I'll avoid adding a new one for isTypeError. See discussion at https://github.com/dart-lang/test/issues/904#issuecomment-580947127

[natebosch]

Would it be sensible for isCastError to match TypeError too?

[leafpetersen]

We want to move away from owning all these is*Error matchers, so I think I'll avoid adding a new one for isTypeError.

That's fine, I just observed the presence of one of them and not the other.

Would it be sensible for isCastError to match TypeError too?

Possibly. All implementations classes in the SDK now implement both, so for SDK errors it will de facto already catch both. Adding an explicit check for TypeError would make that behavior consistent for anybody else implementing CastError. I don't know how many (if any) such implementations exist.

At some point (probably Dart 3) CastError will be removed.

[natebosch]

Ok cool, I think what we can do is wait for an SDK release where CastError is deprecated, mark isCastError deprecated then, and set the lower bound SDK to that version.

This way we'll be less likely to show the message to someone using an older SDK who shouldn't migrate since they'd still get CastError thrown. Our recommended migration path will be isA<TypeError>(), and it sounds like that will be safe to use for any SDK past the point where CastError is deprecated.

[leafpetersen]

SGTM. I landed the CastError deprecation today, I'd guess it will make it into 2.8 but not guaranteed.