enum
fallback design allows for silent API breakages #268
Open
Description
Consider the WpErrorCode
implementation below:
fn showcase(error_code: WpErrorCode) {
if let WpErrorCode::CustomError(error_code_as_string) = error_code {
if error_code_as_string == "foo" {
// handle the "foo" error
}
}
If we were to add a new WpErrorCode::Foo
variant, it'll start to fail and has to be handled as such:
fn showcase(error_code: WpErrorCode) {
if let WpErrorCode::Foo = error_code {
// handle the "foo" error
}
}
This kind of silent API breakages are very dangerous. Our design should allow us to add more error variants without breaking the existing implementation.
The same issue can be seen in other enum
fallbacks as well. For example, if we were to add a new variant to PostTypeCapabilities
, it can break the same way.