Current hardware trends make C++ exceptions harder to justify

Re:Current hardware trends make C++ exceptions harder to jus... by randyrand on Tuesday February 22, 2022 @06:26PM (#30435325)

It should not obfuscate the happy path.

In rust, propagating an error up is as easy as adding a '?' after the function call.

  fn read() -> Result<String, io::Error> {
      let f = File::open("hello.txt")?; // propgate up? 
      let s = f.read_to_string(&mut s)?; // propgate up? 
      Ok(s)
  }

[ Parent | on HN ]

Re:Current hardware trends make C++ exceptions harder to jus... by mcronce on Wednesday February 23, 2022 @01:54AM (#30438444)

Until getting the ? operator in Rust, I always thought I really liked exceptions. After all, what was the alternative? `if err != nil { return nil, err }` everywhere just to propagate errors up and probably ultimately have the process panic when there's an error? "How obnoxious", I thought; the vast majority of the time I'd rather crash and be restarted than attempt to recover and risk severely corrupting state.

Turns out I strongly prefer explicit errors over exceptions, I just also strongly prefer error handling not consuming 75% of the lines on my screen.

And in the cases where I really do prefer a panic, there's always `.unwrap()`

[ Parent | on HN ]