3 ms·

Did anyone else immediate get confused by the assertion that the http code shouldn't know about the database details so the solution is for the database code to

Did anyone else immediate get confused by the assertion that the http code shouldn't know about the database details so the solution is for the database code to embed http details instead? In our project we have a domain types package with errors that permeate these types of boundaries. It's "okay" in the ways everything in Go is "okay". I've yet to see anything I really like in this space.

flimzy 3y ago
Post author here. I probably could have made this a bit more clear, but I feel it was a slight tangent to the main point of the post: In any serious app, I wouldn't actually set an HTTP status directly in the db layer. Rather, I would do what others in this thread have suggested: I'd have a set of domain error types/codes, and my DB layer would set _that_. That domain error value would then implement the `HTTPStatus()` method to return the appropriate status code. This allows you to have multiple "not found" error codes (as an example) for internal use, which all resolve to an HTTP status of 404.
earthboundkid 3y ago
Yeah, you should have an error domain and convert a sql.NotFound error to an app.NotFound error at the boundary. The http handler can then treat those as 404s.
deleted 3y ago
[deleted]
randomdata 3y ago
Yes. In fact, I am continually confused by how as soon as developers see the word "error" they forget how to write software. They can be perfectly competent developers when handling any other type, but as soon as "error" shows up on the screen all bets are off. It is bizarre. Developers as a rule also seem to act strange if you suggest that they made an error. Perhaps the word "error" is triggering in some deep-seated emotional way? I wonder if, in software, we called errors "pineapples" instead if it would avoid triggering such emotions, allowing one to reason about errors in the same rational way they do all other values?

flimzy 3y ago

Post author here. I probably could have made this a bit more clear, but I feel it was a slight tangent to the main point of the post: In any serious app, I wouldn't actually set an HTTP status directly in the db layer. Rather, I would do what others in this thread have suggested: I'd have a set of domain error types/codes, and my DB layer would set _that_. That domain error value would then implement the `HTTPStatus()` method to return the appropriate status code. This allows you to have multiple "not found" error codes (as an example) for internal use, which all resolve to an HTTP status of 404.

earthboundkid 3y ago

Yeah, you should have an error domain and convert a sql.NotFound error to an app.NotFound error at the boundary. The http handler can then treat those as 404s.

deleted 3y ago

[deleted]

randomdata 3y ago

Yes. In fact, I am continually confused by how as soon as developers see the word "error" they forget how to write software. They can be perfectly competent developers when handling any other type, but as soon as "error" shows up on the screen all bets are off. It is bizarre. Developers as a rule also seem to act strange if you suggest that they made an error. Perhaps the word "error" is triggering in some deep-seated emotional way? I wonder if, in software, we called errors "pineapples" instead if it would avoid triggering such emotions, allowing one to reason about errors in the same rational way they do all other values?