3 ms·

Go doesn't ensure that you handle errors, if the function doesn't have a return value other than the error. The compiler will happily let you silently drop the

Go doesn't ensure that you handle errors, if the function doesn't have a return value other than the error. The compiler will happily let you silently drop the result of os.Mkdir() on the floor.

Thaxll 7y ago
I'm no Rust expert, but Rust doesn't enforce that either. There is no language that enforce error checking afaik.
- typon 7y ago
  You have to either propagate the error up the stack or face a panic. Rust does force you to deal with the error.
  - Thaxll 7y ago
    I didn't make myself clear enough, if something returns an error in Rust and you don't check it will it compile or not?
    - typon 7y ago
      It will not compile. (As I said earlier, you can always fallback to a panic aka "I don't wanna deal with the error so let my program crash", but an error will not silently propagate through the stack)
      - cjhopman 7y ago
        That's is completely false, stop spreading misinformation. This code will compile (see https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=050a528df9eecdadf6f65c58d59f62ba https://play.rust-lang.org/?version=stable&mode=debug&editio...): pub fn foo() -> Result<(), i64> { Err(1) } pub fn bar() -> Result<(), ()> { foo(); Ok(()) } It will provide a warning, but there's a ton of stuff in c++ that would throw a warning and you wouldn't say that it "will not compile". A trivial change that still doesn't handle the error would get rid of the warning. pub fn foo() -> Result<(), i64> { Err(1) } pub fn bar() -> Result<(), ()> { println!("{:?}", foo()); Ok(()) }
        eddyb 7y ago
        I wonder if people upthread meant the warning, or e.g. getting the `Foo` in `Result<Foo, BarError>`. (EDIT: nevermind, just looked again and pcwalton was referring to the warning and specifically `Result<(), E>`; oh well) Because the latter is impossible in Rust and probably more relevant to the usual cited issue with Go's pair approach (i.e. using the null/zeroed `Foo` without checking if there was an error). I do agree though that the warning isn't to stop you from not handling the error at all, it's more of a hint that maybe you forgot something. Printing a `Result` may be the legitimate way to handle it in that case, it's largely left to the user to decide what propagates and what doesn't.
- connerruhl 7y ago
  All languages which uses Result or Either types...?
- pcwalton 7y ago
  You get a compiler warning.
munk-a 7y ago
I also generally think that writing boilerplate code is unproductive - golang's error system relies on people pedantically writing boiler plate code constantly among their logic - the result is to obscure the actual logical drive of the code.

Go doesn't ensure that you handle errors, if the function doesn't have a return value other than the error. The compiler will happily let you silently drop the result of os.Mkdir() on the floor.

Thaxll 7y ago

I'm no Rust expert, but Rust doesn't enforce that either. There is no language that enforce error checking afaik.

typon 7y ago
You have to either propagate the error up the stack or face a panic. Rust does force you to deal with the error.
- Thaxll 7y ago
  I didn't make myself clear enough, if something returns an error in Rust and you don't check it will it compile or not?
  - typon 7y ago
    It will not compile. (As I said earlier, you can always fallback to a panic aka "I don't wanna deal with the error so let my program crash", but an error will not silently propagate through the stack)
    - cjhopman 7y ago
      That's is completely false, stop spreading misinformation. This code will compile (see https://play.rust-lang.org/?version=stable&mode=debug&edition=2018&gist=050a528df9eecdadf6f65c58d59f62ba https://play.rust-lang.org/?version=stable&mode=debug&editio...): pub fn foo() -> Result<(), i64> { Err(1) } pub fn bar() -> Result<(), ()> { foo(); Ok(()) } It will provide a warning, but there's a ton of stuff in c++ that would throw a warning and you wouldn't say that it "will not compile". A trivial change that still doesn't handle the error would get rid of the warning. pub fn foo() -> Result<(), i64> { Err(1) } pub fn bar() -> Result<(), ()> { println!("{:?}", foo()); Ok(()) }
      - eddyb 7y ago
        I wonder if people upthread meant the warning, or e.g. getting the `Foo` in `Result<Foo, BarError>`. (EDIT: nevermind, just looked again and pcwalton was referring to the warning and specifically `Result<(), E>`; oh well) Because the latter is impossible in Rust and probably more relevant to the usual cited issue with Go's pair approach (i.e. using the null/zeroed `Foo` without checking if there was an error). I do agree though that the warning isn't to stop you from not handling the error at all, it's more of a hint that maybe you forgot something. Printing a `Result` may be the legitimate way to handle it in that case, it's largely left to the user to decide what propagates and what doesn't.
connerruhl 7y ago
All languages which uses Result or Either types...?
pcwalton 7y ago
You get a compiler warning.

munk-a 7y ago

I also generally think that writing boilerplate code is unproductive - golang's error system relies on people pedantically writing boiler plate code constantly among their logic - the result is to obscure the actual logical drive of the code.