Hacker News Reader

Comment by adrian17 | Hacker News Reader

This paper confirmed what I suspected for some time: exceptions are still the only basically-zero-overhead solution available, which ironically completely justifies their existence in usage patterns where exceptions are actually exceptional. There are times when writing/profiling Rust when I wish I had access to exceptions instead of `Result` propagation.

I do agree with the mentioned design issues though.

View on HN

> There are times when writing/profiling Rust when I wish I had access to exceptions instead of `Result` propagation.

This introduces a whole bunch of design issues, but isn't `panic` (in unwinding mode) basically C++'s exceptions, implementation-wise? Couldn't we use `panic` + `catch_unwind` as a poor man's exception system, should the performance situation really require so?

Also, could we maybe add an attribute `#[exceptional]` to enum variants in a match, that would result in a match implementation closer to exceptions, implementation wise?

The problem is that if you have exception-happy code, then it becomes a scalability limiter for threading.

Yes, if A: you have code that's expected to "fail" relatively many times, and B: this code is also multithreaded. A lot of code doesn't match one or both of these conditions while still being perf-sensitive.

Further, as you can see in other comments, it's not an uncommon belief that exceptions simply shouldn't be used for A (and thus it's reasonable that they aren't optimized for something they aren't supposed to be used for).

Reply on news.ycombinator.com