15.4 · throws, Result, typed throws and mapping errors at boundaries
Errors are part of an API. How you model them decides whether callers can react correctly, or just show “Something went wrong”.
Mental model. Keep low-level errors inside their layer and expose a small set of meaningful errors at each boundary, with enough information to act on.
Modelling failure
Which mechanism to use, and where to translate errors.
- How do you model errors in Swift: throws, Result, optionals and typed throws, and how do you translate them at layer boundaries?
Pick the mechanism by what the caller can do. An optional says “there may be no value” and nothing more (a lookup that finds nothing is not an error). throws…
More in Architecture & API design
- 15.1 · MVC, MVVM, MVP, VIPER, RIBs, TCA and Clean, and unidirectional data flow
- 15.2 · Coordinators, routers and dependency injection
- 15.3 · Feature modules and boundaries, and strangling a legacy codebase
- 15.5 · Designing a Swift API: naming, ownership, documentation and evolution
- 15.6 · SOLID without dogma, and building a platform for many apps
- 15.7 · Effects and cancellation, modelling state, composing reducers
- 15.8 · Closure-based clients, dependency lifetimes, generic repositories and building the graph lazily
- 15.9 · Binary breaks from innocent changes, and what an import exposes
- 15.10 · Types that prevent misuse, error types for libraries, one-shot values and when to trap