I don't think an error-handling mechanism can be said to be "fine" or not without consideration of a specific implementation and domain. For example, I'm using zero-cost EH in a hard real-time system and it turns out people actually want the exceptional path to be fast and…
-
-
-
not merely predictable, which throws quite a wrench in the works. (My alternatives at the time included "SjLj" and "CPS" and did not include "no EH" so I think it was the right choice at the moment, but it's still pretty painful.)
- 8 more replies
New conversation -
-
-
doubly hot take: checked exceptions are very good
-
Yup, I’m OK with checked exceptions.
- 2 more replies
New conversation -
-
-
If only they are marked more strictly by the compiler
-
Yeah, I’m fine with either checked or unchecked exceptions, depending on how strict you like your error handling to be.
- 2 more replies
New conversation -
-
-
hot take for the cold path
-
i have contemplated some nightmarish "catch_panic" shenanigans specifically because i have failure modes i want to handle, but they're in hot enough code that Result'ing everything is substantially detrimental :(
- 9 more replies
New conversation -
-
-
Agree. It's exceptions as control flow that is not fine. When I started
#rustlang it forced my brain to think about when to use panics, unwrap, except, Result and Option. I did give a big thought about it and all of a sudden I felt in control of what I was doing. -
I felt the same. And this new habit somewhat translated to Java and c# for me.
End of conversation
New conversation -
Loading seems to be taking a while.
Twitter may be over capacity or experiencing a momentary hiccup. Try again or visit Twitter Status for more information.