3 ms·

> predictably fails The issue is that, if you've not taken the time to consider the possibility of the error occurring, the failure is by definition unpredicta

> predictably fails The issue is that, if you've not taken the time to consider the possibility of the error occurring, the failure is by definition unpredictable. It's predictable only if the caller 1) knows it can happen, which is often not the case in exception-using code, and 2) specifies the expected behavior, which is by design rarely the case in exception-using code.

vbezhenar 7y ago
Well, I'm writing Java code and exception can be thrown from literally every function call. It's hard to not expect it. It's easier to find code that never throws exceptions. It does not make it any harder to write. Basically you use try-finally for resource release and avoid long living mutable objects (which survive request for typical request-response style server) or write code extra carefully, so those objects don't stay in bad state, but those objects are extremely rare. So in the end it's not hard to write that code.
quotemstr 7y ago
People who write exceptional code consider the possibility of error all the time: there's just no need to mark this constant background possibility with syntax in every possible spot. When exceptional code calls a function, the programmer is saying that the default error behavior --- unwind and propagate to the caller --- is the right thing. It's the right thing in the overwhelming majority of cases, and it's so common that we don't need special syntax to say so. It's as if you're saying there's no difference between using an exception and not "consider[ing] the possibility of [an] error occurring". The lack of special syntax for this default behavior is not the same thing as error sloppiness. Rust's "?" operator does the same damn thing, except that you need to type a character on your keyboard to say so. With respect to the standard error contract, "?" in Rust functions as an "I agree" button. And we all know that people's eyes glaze over when prompted with endless "I agree" buttons and they just click "yes". "?" in Rust is the "I consent" button on a cookie warning popup.

vbezhenar 7y ago

Well, I'm writing Java code and exception can be thrown from literally every function call. It's hard to not expect it. It's easier to find code that never throws exceptions. It does not make it any harder to write. Basically you use try-finally for resource release and avoid long living mutable objects (which survive request for typical request-response style server) or write code extra carefully, so those objects don't stay in bad state, but those objects are extremely rare. So in the end it's not hard to write that code.

quotemstr 7y ago

People who write exceptional code consider the possibility of error all the time: there's just no need to mark this constant background possibility with syntax in every possible spot. When exceptional code calls a function, the programmer is saying that the default error behavior --- unwind and propagate to the caller --- is the right thing. It's the right thing in the overwhelming majority of cases, and it's so common that we don't need special syntax to say so. It's as if you're saying there's no difference between using an exception and not "consider[ing] the possibility of [an] error occurring". The lack of special syntax for this default behavior is not the same thing as error sloppiness. Rust's "?" operator does the same damn thing, except that you need to type a character on your keyboard to say so. With respect to the standard error contract, "?" in Rust functions as an "I agree" button. And we all know that people's eyes glaze over when prompted with endless "I agree" buttons and they just click "yes". "?" in Rust is the "I consent" button on a cookie warning popup.