4 ms·
This paper confirmed what I suspected for some time: exceptions are still the only basically-zero-overhead solution available, which ironically completely justi
by adrian17 5y ago
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.
- cryptonector 5y agoThe problem is that if you have exception-happy code, then it becomes a scalability limiter for threading.
- adrian17 5y agoYes, 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).
- dureuill 5y ago> 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?