I think this article is great but it buries the lede. The cutesy errors are indeed bad but more important is being informative about what actually went wrong and how to resolve it. A while ago I introduced a new error class hierarchy at <JOB> which introduced three distinct families of errors - one that was considered a user error (that would be thrown in response to some action that we can predict happening but not totally prevent), one that is considered to have a user friendly message but be generally unexpected, and anything else. If you try and insert something invalid into the DB you'll get a user unfriendly message - if, within the calling function, you know why your call to the DB would fail with a key collision (for instance) you can create a new chained exception off the original and rethrow with a human readable message - when it hits the top level of execution (assuming nothing catches it) then the error printing logic will iterate through the full chain and print everything human readable and dump the full traces of any errors not marked as user side.

This lets us quickly triage new errors (since known user errors are kept out of the main error log) and presents an easy way to convert logged errors to unlogged ones when we've determined the source of the issue (assuming it's an exception we're comfortable with - a lot of our "user" errors are server-side validation that should be prevented by client-side code).

It also forces any errors that we haven't specifically marked as human-readable to render as "Internal Server Error" which we hate along with supplying an easy route to provide a more meaningful error message.

I never, in my life, want to read an error message that starts with "GuzzleHttp encountered a malformed response from aws. ..." nor do I ever want to see "[SQL1002] The newly inserted row would violate constraint widgets_name_key" - write good errors.