4 ms·

People really hate GoLang's error checking because of the impression that there is a lot of repetition around err != nil statements.

jordwest 10y ago
People really hate handling errors
- cgag 10y ago
  it's not that terrible in languages with abstraction
  - mixedCase 10y ago
    Like the ones where most people end up not actually handling errors where they matter.
    - pcwalton 10y ago
      Which languages specifically, and why do exceptions encourage you to drop errors on the floor?
      - acroback 10y ago
        I think people are misinterpreting support for try catch family in some high level languages as lazy approaches. But truth is it is the programmers who are lazy, we should not blame language for providing a feature which some programmer abuse. I have never seen a Java programmer profiling their code for Memory or CPU at work and I am here running my shitty C code under Valgrind and a profiler all the time. I guess, it is programmers and not the language. Go's error != nil approach though rudimentary actually forces lazy programmers to complain, since they cannot abuse it.
- geofft 10y ago
  Well, the reason why I'm using a high-level programming language is there are a bunch of mechanical things that the computer will do better and more reliably than me. Otherwise I'd just write assembly. What sorts of things fall into this category, and what tradeoffs you're willing to make to have the computer do things for you, is a matter of application (and taste), and so we reasonably have many different programming languages. But it's entirely defensible to want, in the abstract, your language to do repetitive and important work for you. That's what computers are good at.
  - AYBABTME 10y ago
    There's not one reliable, or a set of reliable, way to handle errors. A high level language could handle it for you reliably in the sense of throwing exceptions and hoping you'll catch it. That'd work, you'd get Java software that throws exceptions all the time during normal operations. Errors are valid values, handling them is as normal as handling other values you get from functions.
    - vertex-four 10y ago
      Rust's error handling: let foo = try!(something_that_might_error()) // or soon... let foo = something_that_might_error()? The try!() macro or the ? operator unwrap a Result<T, E> value, which is basically "either the return value or an error value". If it's a return value (T), the macro/operator just gets the value out of it - but if it's an error (E), it will convert the error into your own function's Result<T, E> return type using the From trait, and return that from your own function immediately. The practical result? When I'm parsing input or doing other things that are heavy on errors, I can split it out into another function, wrap every call that might fail in try!(), and only have to actually handle the error once. This allows me to see my code clearer - I can see the success case very clearly, but I'm still forced to decide whether to handle or return errors by the compiler, because there's no other way to get the T out of a Result<T, E>. There's a few other languages which implement this, though they lean towards the functional side a lot more than Rust does. Experience: I'm writing a small internal certificate authority in Go because it has x.509 and signing support in the standard library. I'm no safer by having roughly 3/5 of my lines be if err != nil { return err; }.

jordwest 10y ago

People really hate handling errors

cgag 10y ago
it's not that terrible in languages with abstraction
- mixedCase 10y ago
  Like the ones where most people end up not actually handling errors where they matter.
  - pcwalton 10y ago
    Which languages specifically, and why do exceptions encourage you to drop errors on the floor?
    - acroback 10y ago
      I think people are misinterpreting support for try catch family in some high level languages as lazy approaches. But truth is it is the programmers who are lazy, we should not blame language for providing a feature which some programmer abuse. I have never seen a Java programmer profiling their code for Memory or CPU at work and I am here running my shitty C code under Valgrind and a profiler all the time. I guess, it is programmers and not the language. Go's error != nil approach though rudimentary actually forces lazy programmers to complain, since they cannot abuse it.
geofft 10y ago
Well, the reason why I'm using a high-level programming language is there are a bunch of mechanical things that the computer will do better and more reliably than me. Otherwise I'd just write assembly. What sorts of things fall into this category, and what tradeoffs you're willing to make to have the computer do things for you, is a matter of application (and taste), and so we reasonably have many different programming languages. But it's entirely defensible to want, in the abstract, your language to do repetitive and important work for you. That's what computers are good at.
- AYBABTME 10y ago
  There's not one reliable, or a set of reliable, way to handle errors. A high level language could handle it for you reliably in the sense of throwing exceptions and hoping you'll catch it. That'd work, you'd get Java software that throws exceptions all the time during normal operations. Errors are valid values, handling them is as normal as handling other values you get from functions.
  - vertex-four 10y ago
    Rust's error handling: let foo = try!(something_that_might_error()) // or soon... let foo = something_that_might_error()? The try!() macro or the ? operator unwrap a Result<T, E> value, which is basically "either the return value or an error value". If it's a return value (T), the macro/operator just gets the value out of it - but if it's an error (E), it will convert the error into your own function's Result<T, E> return type using the From trait, and return that from your own function immediately. The practical result? When I'm parsing input or doing other things that are heavy on errors, I can split it out into another function, wrap every call that might fail in try!(), and only have to actually handle the error once. This allows me to see my code clearer - I can see the success case very clearly, but I'm still forced to decide whether to handle or return errors by the compiler, because there's no other way to get the T out of a Result<T, E>. There's a few other languages which implement this, though they lean towards the functional side a lot more than Rust does. Experience: I'm writing a small internal certificate authority in Go because it has x.509 and signing support in the standard library. I'm no safer by having roughly 3/5 of my lines be if err != nil { return err; }.