Hacker Newsnew | past | comments | ask | show | jobs | submitlogin

> That's still roughly 7000-3000 times slower than a plain return. I'm not convinced the extra overhead of an entirely separate control flow mechanism will ever be worth it in any language that cares about performance. Especially since I haven't heard many complaints about the way Rust does things.

Ah, I did not mean to make a case for or against exception-based error handling. Only that it's not as expensive anymore, and that other operations do not necessarily use it: int.TryParse, dict.TryGetValue, encoding.TryGetBytes, etc.

I think the way Rust does it with Result<T, E> and, most importantly, implicit returns is the error handling perfected. You can criticize the language for being on the more verbose side, especially if you are not writing an OS kernel or a driver, but in terms of error handling while preserving the richness of error state it is by far the best per LOC.

One thing to note is, as usual, the Rust style error handling is not free either and you end up paying with at least a single branch in a happy path for each call that may error out provided it's not inlined and error check is not optimized away, and the additional codegen that is needed for blocks that e.g. construct a particular error and return, something that exception handling does "outside" of regular executed code (yes, with disproportionately higher cost but still).



Guidelines | FAQ | Lists | API | Security | Legal | Apply to YC | Contact

Search: