Ecto documentation is pretty old in a lot of places, and I wouldn’t necessarily take it as a best practices guide for my application programming in general. It just covers so many use cases that sometimes some contrived examples would be needed.

I would probably stick to error handling as needed. Use with blocks to handle your happy path cases, then use the fallback controller (if you’re using Phoenix) to handle common errors, e.g. changeset errors. (If you’re not familiar, this is what the Phoenix generators spit out, I believe it’s the phx.gen.html generators that would have examples). For one-off “errors”, just use a custom with...else statement to handle that specific error. Then add common errors to the fallback controller as needed.

The bang functions can be useful in certain circumstances. For example, if using Repo.one! in a controller, that can automatically return 404 in a Phoenix controller. (I believe this is the default Phoenix behavior, my Phoenix is a little rusty ATM.)

My perspective is the Repos job is executing queries and dealing with resulting data. Any failures of the way queries or results are shaped like only produce exceptions on bang functions.

Repo however expects a working connection to the db. So any problems with that are indeed exceptional and therefore raise exceptions. Problems with connections should be dealt with at the level of connection handling / the db pool. Not at the level of some code trying to run a query.