3 ms·

Absolutely. Even after "compressing" my code as much as possible, it looks as if 2/3 of a Go program is pure error handling and no business logic. I just don't

by papito 4y ago

Absolutely. Even after "compressing" my code as much as possible, it looks as if 2/3 of a Go program is pure error handling and no business logic. I just don't understand this militant objection toward exceptions now. Even back in the days of slower virtual machines and crappier hardware, we were fine, and now it's code red! Get rid of exceptions! Performance! This is in an era of tech where everyone is building BAD distributed systems, with non-optimized databases, a fur ball of slow HTTP queries, and giant payloads. Exceptions are the least of your concerns.

carlmr 4y ago
>it looks as if 2/3 of a Go program is pure error handling and no business logic. This is exactly why it's good. It forces developers to think about things outside the happy path business logic. And it does this at the point where they know best what such an error could mean. Proponents of exceptions let their users catch the exceptions they overlooked. If you ask me Go is not forcing this enough, the ML style Result types in Rust are a much better abstraction here.
- MrYellowP 4y ago
  > This is exactly why it's good. How did we manage to get this far before people ~~went insane~~ decided that this is somehow favourable?
  - mindwok 4y ago
    After working in an SRE-type role on a codebase full of unchecked exceptions, or exceptions that are caught at the wrong levels because programmers just want their code to work - forcing the explicit handling of errors is favourable because it requires developers to think about what they really want to happen when something goes wrong at this point in the code. Whereas without it, often they will simply catch the exception and continue on silently, or re-raise it without proper context. Conversely, sometimes there are really simple cases that are totally ignored by programmers because they forget that an exception might be thrown. The worst offender in my experience is in Python where people assume the existence of dictionary keys and get KeyError exceptions, or NoneType exceptions. Without type hints, there's no mechanism to warn you as you write the code that these things could occur. So programmers don't plan for it. If there are explicit errors, the programmer is forced to consider the case that the key they want doesn't exist, or that this variable isn't actually the type they expect (static typing helps here too). In general, I think this prevents footguns when you are working on large programs. It's worth the verbosity.
    - MrYellowP 4y ago
      See, you perfectly explain why this is the completely wrong approach. You have a headache and take painkillers, believing it's going to cure it. No, it doesn't cure the headache, it just masks it out. The cure is teaching people how to actually program the machines. That's all it takes. Decades of abstraction and piling up more and more nonsense eventually led to the situation we are in now, where people praise bullshit which wouldn't be necessary if people had actually learned how to program the machine and how to do it properly. Instead people need more and more help to do even the simplest things because they've never learned how to do things the right way. So now idiots require tools preventing them from making mistakes they wouldn't be making if they were properly educated!

by papito 4y ago

carlmr 4y ago

>it looks as if 2/3 of a Go program is pure error handling and no business logic. This is exactly why it's good. It forces developers to think about things outside the happy path business logic. And it does this at the point where they know best what such an error could mean. Proponents of exceptions let their users catch the exceptions they overlooked. If you ask me Go is not forcing this enough, the ML style Result types in Rust are a much better abstraction here.

MrYellowP 4y ago
> This is exactly why it's good. How did we manage to get this far before people ~~went insane~~ decided that this is somehow favourable?
- mindwok 4y ago
  After working in an SRE-type role on a codebase full of unchecked exceptions, or exceptions that are caught at the wrong levels because programmers just want their code to work - forcing the explicit handling of errors is favourable because it requires developers to think about what they really want to happen when something goes wrong at this point in the code. Whereas without it, often they will simply catch the exception and continue on silently, or re-raise it without proper context. Conversely, sometimes there are really simple cases that are totally ignored by programmers because they forget that an exception might be thrown. The worst offender in my experience is in Python where people assume the existence of dictionary keys and get KeyError exceptions, or NoneType exceptions. Without type hints, there's no mechanism to warn you as you write the code that these things could occur. So programmers don't plan for it. If there are explicit errors, the programmer is forced to consider the case that the key they want doesn't exist, or that this variable isn't actually the type they expect (static typing helps here too). In general, I think this prevents footguns when you are working on large programs. It's worth the verbosity.
  - MrYellowP 4y ago
    See, you perfectly explain why this is the completely wrong approach. You have a headache and take painkillers, believing it's going to cure it. No, it doesn't cure the headache, it just masks it out. The cure is teaching people how to actually program the machines. That's all it takes. Decades of abstraction and piling up more and more nonsense eventually led to the situation we are in now, where people praise bullshit which wouldn't be necessary if people had actually learned how to program the machine and how to do it properly. Instead people need more and more help to do even the simplest things because they've never learned how to do things the right way. So now idiots require tools preventing them from making mistakes they wouldn't be making if they were properly educated!