Skip to content

enum fallback design allows for silent API breakages #268

Open
@oguzkocer

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.

Metadata

Assignees

Type

No type

Projects

No projects

Relationships

None yet

Development

No branches or pull requests

Issue actions