Need/problem
The convention of subclassing requiring errors to conform to FatalError adds friction while providing little value.
Motivation
I cargo-cultured this pattern from another repository. The motivation behind is was to signal whether an error should be reported or not (bug or abort), and whether its description should be output or not (silent or not). We haven’t leveraged the former, and I believe not that much of the latter. So, I started wondering whether having such a pattern in the codebase makes sense. It’s a pattern that new contributors have to get familiar with.
Detailed design
I propose that we stop using it and embrace the Error protocol and require it to conform to CustomStringConvertible through a custom SwiftLint rule. This is important to ensure that users get a nice description when we present the errors.
Drawbacks
- If we ever want to introduce error tracking, we won’t be able to determine which errors are handled and which are not.
- We’ll have a legacy pattern in the codebase, so it might confuse developers even more
Alternatives
Leave things as they are. Sure, it’s a bit of friction, but not too much compared to other areas of the codebase.
Adoption strategy
- I’d document the pattern
- Add a custom SwiftLint rule to ensure errors conform to
CustomStringConvertibleand provide a description fixing the issues that arise.
How we teach this
I’d document this pattern in our contributor’s documentation