5 ms·

So long as we can all agree that it feels super bad, I guess this is fine Exceptions feel super good, even as you're taking too many shortcuts and glossing ove

So long as we can all agree that it feels super bad, I guess this is fine Exceptions feel super good, even as you're taking too many shortcuts and glossing over things. Proper handling of the unhappy paths is often going to feel like a slog, because it often is complicated, and it's often a slog. Glossing over error handling in golang can feel bad exactly when it should.

KirinDave 7y ago
> Exceptions feel super good, even as you're taking too many shortcuts and glossing over things. I'm not sure I follow this talk about "short cuts.". Exceptions provide stronger guarantees by default than multiple-value-bind and manual if statements. Your code fails closed as opposed to open. > Proper handling of the unhappy paths is often going to feel like a slog, because it often is complicated, and it's often a slog. I'm used to languages where this generally isn't the case, but sure. Why twist the knife in the wound though? > Glossing over error handling in golang can feel bad exactly when it should. When you capture but fail to check an errval and an untraceable default value starts rattling around inside your code causing unexpected behavior? It's like an NPE but worse because it won't immediately trap. It's more like a double free.
- schrodinger 7y ago
  go vet catches that scenario and won’t pass CI. You have to explicitly decide to ignore it by using an underscore for the err value and then you get just what you asked for.
  - KirinDave 7y ago
    Sure, but it doesn't catch the case where you have multiple error variables in scope and you refer to the wrong one in one place but not the other or if you reuse an error. I've seen that happen more than a few times. Some of it in new production code.
  - apta 7y ago
    fmt.Println says otherwise. That and it's possible to overwrite previous error variables, something that is not possible with exceptions.
philwelch 7y ago
In some contexts, exceptions are just cleaner and easier. If I’m writing a web backend, my error handling is going to almost always be, “stop trying to do things and generate a 4xx/5xx response”. Throwing an exception from anywhere and then handling it at the top of the request handling does that without having to tediously carry errors all the way up the call stack.
- stcredzero 7y ago
  In some contexts, exceptions are just cleaner and easier. Definitely. The question is, are the benefits in those contexts worth the cost of the potential abuses? As a codebase and company get larger and larger, the higher the probability that a problem will get into the codebase. There is an analogy here with C++ templates and with method_missing meta-programming. There are some contexts where they make things a lot easier. However, in a large codebase, the probability that some programmer, somewhere is going to cause a costly problem with a bit of nifty overreach goes up and up.
  - philwelch 7y ago
    While true, HTTP services in particular are a very, very common context.
    - mikeschinkel 7y ago
      Then use panic() and recover() for that special type of use-case. Just as easy as exception handling.
      - philwelch 7y ago
        That's just exception handling with extra steps! ;)
- mikeschinkel 7y ago
  But then you have to spend lots of extra time trying to discern between the errors that were okay, and the errors that actually indicate flaws in your code. As they say, an ounce of prevention...

KirinDave 7y ago

> Exceptions feel super good, even as you're taking too many shortcuts and glossing over things. I'm not sure I follow this talk about "short cuts.". Exceptions provide stronger guarantees by default than multiple-value-bind and manual if statements. Your code fails closed as opposed to open. > Proper handling of the unhappy paths is often going to feel like a slog, because it often is complicated, and it's often a slog. I'm used to languages where this generally isn't the case, but sure. Why twist the knife in the wound though? > Glossing over error handling in golang can feel bad exactly when it should. When you capture but fail to check an errval and an untraceable default value starts rattling around inside your code causing unexpected behavior? It's like an NPE but worse because it won't immediately trap. It's more like a double free.

schrodinger 7y ago
go vet catches that scenario and won’t pass CI. You have to explicitly decide to ignore it by using an underscore for the err value and then you get just what you asked for.
- KirinDave 7y ago
  Sure, but it doesn't catch the case where you have multiple error variables in scope and you refer to the wrong one in one place but not the other or if you reuse an error. I've seen that happen more than a few times. Some of it in new production code.
- apta 7y ago
  fmt.Println says otherwise. That and it's possible to overwrite previous error variables, something that is not possible with exceptions.

philwelch 7y ago

In some contexts, exceptions are just cleaner and easier. If I’m writing a web backend, my error handling is going to almost always be, “stop trying to do things and generate a 4xx/5xx response”. Throwing an exception from anywhere and then handling it at the top of the request handling does that without having to tediously carry errors all the way up the call stack.

stcredzero 7y ago
In some contexts, exceptions are just cleaner and easier. Definitely. The question is, are the benefits in those contexts worth the cost of the potential abuses? As a codebase and company get larger and larger, the higher the probability that a problem will get into the codebase. There is an analogy here with C++ templates and with method_missing meta-programming. There are some contexts where they make things a lot easier. However, in a large codebase, the probability that some programmer, somewhere is going to cause a costly problem with a bit of nifty overreach goes up and up.
- philwelch 7y ago
  While true, HTTP services in particular are a very, very common context.
  - mikeschinkel 7y ago
    Then use panic() and recover() for that special type of use-case. Just as easy as exception handling.
    - philwelch 7y ago
      That's just exception handling with extra steps! ;)
mikeschinkel 7y ago
But then you have to spend lots of extra time trying to discern between the errors that were okay, and the errors that actually indicate flaws in your code. As they say, an ounce of prevention...