> The idea that error handling is "not part of the code" is silly though. My impression of people that hate Go's explicit error handling is that they don't want to deal with errors properly at all. "Just catch exceptions in main and print a stack trace, it's fine."
I'm honestly asking as someone neutral in this, what is the difference? What is the difference between building out a stack trace yourself by handling errors manually, and just using exceptions?
I have not seen anyone provide a practical reason that you get any more information from Golangs error handling than you do from an exception. It seems like exceptions provide the best of both worlds, where you can be as specific or as general as you want, whereas Golang forces you to be specific every time.
I don't see the point of being forced to deal with an "invalid sql" error. I want the route to error out in that case because it shouldn't even make it to prod. Then I fix the SQL and will never have that error in that route again.
The biggest difference is that you can see where errors can happen and are forced to consider them. For example imagine you are writing a GUI app with an integer input field.
With exception style code the overwhelming temptation will be to call `string_to_int()` and forget that it might throw an exception.
Cut to your app crashing when someone types an invalid number.
Now, you can handle errors like this properly with exceptions, and checked exceptions are used sometimes. But generally it's extremely tedious and verbose (even more than in Go!) and people don't bother.
There's also the fact that stack traces are not proper error messages. Ordinary users don't understand them. I don't want to have to debug your code when something goes wrong. People generally disabled them entirely on web services (Go's main target) due to security fears.
> But generally it's extremely tedious and verbose
Is it? In my experience it's very short, especially considering you can catch multiple errors. Do my users really need a different error message for "invalid sql" vs "sql connection timeout?" They don't need to know any of that.
> There's also the fact that stack traces are not proper error messages
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
> 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.
> What is the difference between building out a stack trace yourself by handling errors manually, and just using exceptions?
You cannot force your dependencies to hand you a stack trace with every error. But in languages that use exceptions a stack trace can be provided for "free" -- not free in runtime cost, but certainly free in development cost.
This one frustrates me a lot. Not getting a proper trace of the lib code that generated an error makes debugging what _exactly_ is going on much more of a PITA. Sure, I can annotate errors in _my_ code all day long, but getting a full trace is a pain.
I'm honestly asking as someone neutral in this, what is the difference? What is the difference between building out a stack trace yourself by handling errors manually, and just using exceptions?
I have not seen anyone provide a practical reason that you get any more information from Golangs error handling than you do from an exception. It seems like exceptions provide the best of both worlds, where you can be as specific or as general as you want, whereas Golang forces you to be specific every time.
I don't see the point of being forced to deal with an "invalid sql" error. I want the route to error out in that case because it shouldn't even make it to prod. Then I fix the SQL and will never have that error in that route again.