|
For what it's worth this is a decent approach for naïve applications such as a contact form or similar. This doesn't really work when you get into the kind of validations that are really important in web applications with multiple users, the canonical example that springs to mind is email uniqueness validation. If one lets the database err out with a constraint violation, and bubble the panic (thus 5XX) up to the browser, that'd be a terrible user experience. As such I have the concept of domain errors in my application, they have the structure `map[string]string`, and are related to a domain object (User, Message, Project, etc). The package is `myapp/domain/errors`, and `domainError.ValidationError` is a concept shared by my persistence layer, as well as http handling layer, when a given entity is to be persisted, the backend might return a `domainError.ValidationError`, or there may be a legitimate (connection lost, for example) error, so they are handled through a late call to infer the `err.(type)`, and switch modes based on whether it's a validation error, something more fundamental, or simply nil. Separating the notion of a validationError to something that can be propagated through your own microframework scales much better than this ad-hoc mechanism. That said, the OP is right that this works in this case. |