-
Some good thoughts from a SlateDB dev, regarding initial principles for errors in SlateDB, derived from experience with Kafka:
- Keep public errors separate from internal errors. The set of public errors should be kept minimal and new errors should be highly scrutinized. For internal errors, we can go to town since they can be refactored and consolidated over time without affecting the user.
- Public errors should be prescriptive. Can an operation be retried? Is the database left in an inconsistent state? Can a transaction be aborted? What should the user actually do when the error is encountered? The error should have clear guidance.
- Prefer coarse error types with rich error messages. There are probably hundreds of cases where the database can enter an invalid state. We don’t need a separate type for each of them. We can use a single FatalError and pack as much information into the error message as is necessary to diagnose the root cause.
(via Chris Riccomini)
Tags: errors api design slatedb api-design error-handling exceptions architecture