Update the kind of error the CFE produces for the failing patterns in irrefutable contexts

[chloestefantsova]

The runtime error that the CFE produces on a failed pattern match in an irrefutable context should be changed. Currently, the CFE uses ReachabilityError as a placeholder.

The following is a relevant and very helpful fragment from an offline conversation with @lrhn. Thank you for the clear and elaborate guidance, as always, Lasse!

First of all, a pattern in an irrefutable context cannot fail to match. That should be a compile-time error.
If it fails anyway, it's either because a ! or as failed, and then it's a TypeError as usual.
Or it's a list or map pattern which doesn't have the required elements/keys, in which case ... I'd be fine with just doing list[2] and letting it throw, but map["key"] won't throw, it just returns null, and we should throw if the key isn't there, even if the value pattern would accept null. So we do need to decide what to throw in that case.

Not inventing a new error would be nice. ReachabilityError is definitely a strawman name 🙂

I'd probably go with StateError. The state of the object being matched does not support the operation required (having a [2] element or ["key"] entry).
It's not an ArgumentError, because there is no function and no argument.
It's could be UnsupportedError, but that's usually reserved for an object which will never support that operation, and a list or map can be updated to have the value.
So, StateError matches, a state-based inability to support the operation, not an inherent inability like adding to an unmodifiable list.

That means it requires a message. I'd go with:

  StateError("List pattern requires ${_patternMinLength} elements, list has only ${list.length}")
  StateError("Map pattern requires key not provided by map value.")

[chloestefantsova]

/cc @eernstg

[eernstg]

The situation would be that there is an irrefutable pattern matching process that failed (so we're decomposing objects, and it is statically guaranteed to succeed except casts from dynamic, cast patterns, !, list length, map entries, and perhaps a few more).

I think this means that it is a "PatternMatchingError": The pattern did not match, and the current computation completes by throwing an exception. Many of the same situations would cause a pattern matching failure (that is: try the next one) in a refutable context, a couple of them have different syntax (! for the throwing null check, ? for the failing one), but most of them have the same syntax, and they are clearly similar in many ways. I think that justifies thinking about this situation as an outcome of a pattern matching process. It is arguably an Error, just like 1 ~/ 0 is an error, because these checks are implicitly indicating that "this will work, trust me!", and it's a bug when it doesn't work.

Perhaps a StateError("... a message that says pattern matching error ...") is fine. Otherwise, it might be useful to introduce a new PatternMatchingError.

[lrhn]

It's a good distinction to look at which things would throw in a refutable pattern too, and which would fail it.

The implicit downcast from dynamic probably won't happen in a refutable pattern, we'll do a real type check first and reject instead. However, a failing implicit downcast should throw what it always throws, not something new just because it happens in a pattern. That would just be confusing, since the downcast is not really related to the pattern, it's more of a general property of putting dynamic into a typed context.
(We could argue that checking a typed pattern against a dynamic matched value type is treated as a refutable pattern in an irrefutable context, and it is a pattern failure. That would also be a consistent story, we'll have
to decide in the specification of coercions. But if so, we should choose what to throw, and TypeError is still
the best choice, so it's really just a philosophical distinction.)

The as and ! patterns will throw in refutable patterns too, and it'll be a TypeError, just like a failing as or ! outside of a pattern. Again, no need to do something new.

A throwing getter or other member, including a contravariant return type check, will also throw as normal.

It's really only failing list and map patterns that are pattern failures, not just normal errors that happen on the way to doing the pattern match.
They are the only patterns which can still be refuted in an irrefutable context where the pattern has been successfully type checked against the static matched value type, because they check properties not guaranteed by the type.

Still think StateError is a good choice for those.

[chloestefantsova]

As of https://dart-review.googlesource.com/c/sdk/+/291063, a StateError is used in place of the ReachabilityError. The message string doesn't provide any details though and simply says "Pattern matching error".