Tim McNamara - 4 levels of error handling
Vložit
- čas přidán 10. 04. 2024
- Rust's errors can be confusing. Strengthen your code one level at a time. Learn how to start with an easy path and grow as you knowledge increases. We start with 'good enough' approaches, then move towards something that's more idiomatic over time. This talk is highly interactive with lots of live coding and examples to follow. So grab your laptop and follow-along!
- Věda a technologie
Excellent talk!
Wait, who's on first?
Not a hit on the speaker, oc. It's just another part of rust that's a bit wonky atm.
The lack of exceptions is a sign of quality. Exceptions should've never been a thing.
Exceptions do their job well, they just don't work without garbage collection.
@@ArmandoDoval they do not, why we still allow hidden control flow a la GOTO in our codebases several decades after decrying the very same for its faults is beyond me
I think Rust's support for exceptions is well handled via panic_any. It's for truly performance critical code where any failure means aborting the whole task and only hot-path performance matters. You really barely ever want to use it, but it's available for the extremes.
Exceptions work in C++ without GC.
They also don't have to be "hidden"; the point of checked exceptions is that they represent exceptional cases that can arise even when using an API within its contract
People make a fuss about checked exceptions (the initial Java class library didn't use them particularly well) but they're not dissimilar to specifying the Err side of a Result in terms of verbiage.
Nothing wrong with exceptions. As any tool, can be used in right or wrong way. If you volunteer to shot your own leg and use them as goto (as mentioned in comments) nothing can help you, really. You will find your way with any tool you have.
I’m new to rust, but error handling looks like a pain. Though, I have an impression I maybe missing something. It looks unnecessary complicated. In the most of the cases I would like to have just something generic were I just can return an error, all receiver needs to know is if that was failure or success. I do not want new types. I also want to be able to handle all library errors in the same way - again in the most of the cases I just want to know if things failed or not, do not need specifics. All in all, analogue of “throws Exception”, in Java world.
The Scammer. 😂😂😂