4 ms·

It’s largely difficult because either: - you’re working in a language that doesn’t have checked exceptions, so the set of potential errors and the set of poten

It’s largely difficult because either: - you’re working in a language that doesn’t have checked exceptions, so the set of potential errors and the set of potentially error-raising calls is infinite but unknowable - you’re working in a language that has checked exceptions, and you hate that it makes you do work, so you catch-rethrow runtime errors that recreate the first scenario - you’re working in a language that has checked exceptions, but someone else did the second scenario so you’re in the first scenario anyway

xboxnolifes 2y ago
The unchecked exception example doesn't seem any different than using a dynamically typed language and reading return values, and exceptions seem to get significantly more hate than those.
- eyelidlessness 2y ago
  Because even in a dynamically typed language you can generally go look at what the function returns. You can’t look at what it throws without walking the entire call stack and inspecting the source code of the runtime.
groestl 2y ago
Other programmers tend to be bad at reliably cleaning up resources such as file handles, locks etc, so I need to inspect the whole invocation tree anyways to have an understanding of what runtime implications I've summoned by invoking other people's code. As for myself, I've lived through the hell that are checked exceptions in Java. You learn that compositionality and checked exceptions are at odds when you try to insert a remoting layer into an application that has grown without IOExceptions. Then you learn that it's actually not necessary to know the set of possible errors, just make sure that you're not a bad programmer as in my first paragraph, and everyone will be fine. This is also something that you can learn from Exceptional C++.
- fiddlerwoaroof 2y ago
  Yeah, I’ve never understood the complaints about exceptions either: most of the time you want the exceptions to just bubble up anyway because, in that case, you only have to think about the contracts of the functions you interact with and not about the unusual states you might be in. Return-type or return-value based error handling has always seemed to me to be significantly worse.

xboxnolifes 2y ago

The unchecked exception example doesn't seem any different than using a dynamically typed language and reading return values, and exceptions seem to get significantly more hate than those.

eyelidlessness 2y ago
Because even in a dynamically typed language you can generally go look at what the function returns. You can’t look at what it throws without walking the entire call stack and inspecting the source code of the runtime.

groestl 2y ago

Other programmers tend to be bad at reliably cleaning up resources such as file handles, locks etc, so I need to inspect the whole invocation tree anyways to have an understanding of what runtime implications I've summoned by invoking other people's code. As for myself, I've lived through the hell that are checked exceptions in Java. You learn that compositionality and checked exceptions are at odds when you try to insert a remoting layer into an application that has grown without IOExceptions. Then you learn that it's actually not necessary to know the set of possible errors, just make sure that you're not a bad programmer as in my first paragraph, and everyone will be fine. This is also something that you can learn from Exceptional C++.

fiddlerwoaroof 2y ago
Yeah, I’ve never understood the complaints about exceptions either: most of the time you want the exceptions to just bubble up anyway because, in that case, you only have to think about the contracts of the functions you interact with and not about the unusual states you might be in. Return-type or return-value based error handling has always seemed to me to be significantly worse.