News for hackers. Stuff that matters.
Re:Current hardware trends make C++ exceptions harder to jus... by tremon on Tuesday February 22, 2022 @06:17PM (#30435240)
They should be used when standard return value errors are measured to be impacting perf (ie. exceedingly rarely)

I disagree with this. I think they should be used whenever "standard" return value error handling starts to obfuscate the normal operation (happy flow) of the code. This impact on developer performance happens a lot sooner than the measurable machine performance.

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)
  }
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()`