4 ms·

> 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

> 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.

IshKebab 3y ago
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.
- Capricorn2481 3y ago
  > 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
  - IshKebab 3y ago
    > 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.
    - Capricorn2481 3y ago
      > "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. Lol.
throw-the-towel 3y ago
> 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.
- lsaferite 3y ago
  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.

IshKebab 3y ago

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.

Capricorn2481 3y ago
> 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
- IshKebab 3y ago
  > 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.
  - Capricorn2481 3y ago
    > "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. Lol.

throw-the-towel 3y ago

> 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.

lsaferite 3y ago
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.