Specify what exceptions get thrown in NNBD feature spec.

[crelier]

The NNBD spec should be more specific about what exact exceptions (or errors) should be thrown at runtime.

Here is a list (may not be exhaustive) of cases requiring a throw:

• a read to a late field or variable without an initializer expression.
• a write to a field or variable which is marked final and late.
• null check detecting a null instance.
• missing required named parameter (NoSuchMethodError?).
• calling the .length setter on a List of non-nullable element type with an argument greater than the current length of the list is a runtime error.
• illegal instantiation of type parameter at runtime (e.g. substituting a non-nullable type parameter with a nullable type).

[lrhn]

I propose, for language errors:

• New LateInitializationError for late variable errors (with different messages for reading an uninitialized variable and for writing an initialized final variable).
• CastError for null-check operator (it basically does as static-type-without-null).
• NoSuchMethodError for omitting required parameter, whether named or positional.
• TypeError for invalid type arguments, like now.

We could use StateError for late variables, but I think I'll prefer to keep that for objects currently being in the wrong state. It's not mentioned in the language specification yet.

For library errors, the class gets to decide, not the language specifications. There are no rules, and we usually document just as "must" or "must not", without saying which error is thrown if that is violated.
We'll probably use:

• UnsupportedError for growing lists of non-nullable elements, documented on List.length as "must not set the length to a value greater than the current length if null is not a valid element of the list"..
• StateError or TypeError for reading current of a Iterator of non-nullable elements when there is no current. (The simplest migration is get current => _current as E; which throws TypeError if _current (with type E?) is null and E is not nullable). I'll recommend StateError, but not require it.

Edit: Removed CastError from the list. The language specification already does not mention CastError, and there are wishes from JS compilers to not have to distinguish between different dynamic type errors.

[leafpetersen]

Leaving this open to track making the core library changes to give useful error messages.

[lrhn]

See #787 and #806.

[leafpetersen]

This is done.