Github user srowen commented on the issue:
https://github.com/apache/spark/pull/22039
Yes, I agree about the future-proofing problem. However, at the moment, new
future cases will also not cause any compile problem, but will just also
trigger a MatchError. This is, simply, always a problem, that new future
unmatched cases aren't handled and trigger an exception at runtime not compile
time. These changes at least make the error more explicit.
Of course, if the default case in any of these situations really had a
valid outcome, then throwing an exception is wrong. But I don't see any reason
to believe that, currently, a match is incorrectly handled as MatchError. I
think it's OK to remove the compile-time warning by supplying a good default
exception case. I think tests will help figure out where those default cases
are no longer appropriate.
Yes, "quick hack", but, as opposed to what in these specific cases?
---
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
