Preparing for Change: Safe Switching over Sealed APIs

An exhaustive switch on a sealed type covers the permitted subtypes the compiler knows about; it does not cover future additions, which can cause MatchException at run time. API authors should document the expected evolution of sealed types so that client code can choose how to handle future additions. It is almost never necessary to use default when switching over a sealed type—and often not the best option.