> Do my users really need a different error message for "invalid sql" vs "sql connection timeout?"
Yes! A connection timeout means it might work if they try again later. Invalid SQL means it's not going to fix itself.
But in any case, the error messages are probably the minor part. The bigger issue is about properly handling errors and not just crashing the whole program / endpoint handler when something goes wrong.
> I would say there's not a proper error message to derive from explicitly handling sql errors. Certainly not a different message per error. I would rather capture all of it and say something like "Something went wrong while accessing the database. Contact an admin." Then log the stack trace for devs
Ugh these are the worst errors. Think about the best possible action that the user could take for different failure modes.
"Contact an admin" is pretty much always bottom of the list because it rarely works. More likely options are "try again later", "try different inputs", "clear caches and cookies", "Google a more specific error".
Giving up on making an error message because you only have a stack trace and don't want to show it means users can't pick between those actions.
If you have written a "something went wrong" error I literally hate you.
> "Contact an admin" is pretty much always bottom of the list because it rarely works. More likely options are "try again later", "try different inputs", "clear caches and cookies", "Google a more specific error"
You're totally misunderstanding what I'm saying. If I have an error the user can act on, I'll make that error message for them. If they can't act on it, I will make a generic catcher and ask them to contact an admin because that's the only thing they can do. It is not my experience that any of these things you've written (try again later, try a different input) are applicable when an error comes up in my apps. It's always an unexpected bug a developer needs to fix, because we've already handled the other error paths. And the bug is not from "not explicitly handling the error."
> Think about the best possible action that the user could take for different failure modes.
What if contacting an admin IS the best possible action? Which is what I'm referring to.
In the case of invalid sql, your route should crash because it's broken. Or catch it and stop it. It's functionally the same thing.
You seem to be under the impression that having exceptions mean people can't handle errors explicitly? It just prevents the plumbing of manually bubbling up the error. It means you can do so MORE granularly. Also, there are some errors that are functionally the same whether you handle them explicitly or not. There are unexpected errors, and even Golang won't save you from that. Golang doesn't even care if you handle an error. It will compile fine. Even PHP will tell you if you haven't handled an exception.
> If you have written a "something went wrong" error I literally hate you.
> You seem to be under the impression that having exceptions mean people can't handle errors explicitly?
Not at all! It's possible, but it's very tedious, and the lazy "catch it in main" option is so easy that in practice when you look at code that uses exceptions people actually don't handle errors explicitly.
> It means you can do so MORE granularly.
Again, it doesn't just mean that you can; it means that you will. And for proper production software that's not a good thing.
> There are unexpected errors
Only in languages with exceptions. In a language like Rust there are no unexpected errors; you have to handle errors or the compiler will shout at you.
That has nothing to do with having exceptions, Rust just has a good type system (something go doesn't have).
But again, handling an error doesn't necessarily prevent bugs. Just because you handled an error doesn't mean the error won't happen in Prod. It just means when it does, you wrote a message for it or custom behavior. Which could be good, or it might be functionally as effective as returning a stack traces message. It depends on the situation.
For what it's worth, I've never seen people not handle errors that the user could do anything with. If it's relevant to the user, we handle it.
It absolutely does. Checked exceptions sort of half get there too but they are quite rarely used (I think they are used in Android quite well). They were actually removed from C++ because literally nobody used them.
> handling an error doesn't necessarily prevent bugs.
I never made that claim.
> I've never seen people not handle errors that the user could do anything with.
We already talked about "something went wrong" messages. Surely you have seen one of those?
> In a language like Rust there are no unexpected errors
What? Of course there is. Rust added panic! exactly because unexpected errors are quite possible.
Unexpected errors, or exceptions as they are conventionally known, are a condition that arises when the programmer made a mistake. Rust does not have a complete type system. Mistakes that only show up at runtime absolutely can be made.
Yes! A connection timeout means it might work if they try again later. Invalid SQL means it's not going to fix itself.
But in any case, the error messages are probably the minor part. The bigger issue is about properly handling errors and not just crashing the whole program / endpoint handler when something goes wrong.
> I would say there's not a proper error message to derive from explicitly handling sql errors. Certainly not a different message per error. I would rather capture all of it and say something like "Something went wrong while accessing the database. Contact an admin." Then log the stack trace for devs
Ugh these are the worst errors. Think about the best possible action that the user could take for different failure modes.
"Contact an admin" is pretty much always bottom of the list because it rarely works. More likely options are "try again later", "try different inputs", "clear caches and cookies", "Google a more specific error".
Giving up on making an error message because you only have a stack trace and don't want to show it means users can't pick between those actions.
If you have written a "something went wrong" error I literally hate you.