3 ms·
> I'm not sure what you found in (checked) exceptions. I could copy/paste the entire article here... but it would be easier if you could take a gander: https:/
by breadwinner 1y ago
> I'm not sure what you found in (checked) exceptions.
I could copy/paste the entire article here... but it would be easier if you could take a gander: https://mckoder.medium.com/the-achilles-heel-of-c-why-its-exception-handling-falls-short-f7f932488aba https://mckoder.medium.com/the-achilles-heel-of-c-why-its-ex...
Summary:
Crashy code: You have no compiler-enforced way to know what exceptions might be thrown from a method or library.
More crashy code: If a method starts throwing a new exception, you might not realize you need to update your error handling.
Dead code: If a method stops throwing an exception, old catch blocks may linger, becoming dead code.
- Kwpolska 1y agoNone of those arguments are convincing. In many cases, you can't handle errors more reasonably than just crashing or telling the user something went wrong. Java has RuntimeExceptions, which do not have to be declared in the function signature. Division by zero, or trying to index an array out of bounds, and the dreaded NullPointerException, are some examples of RuntimeExceptions.
- breadwinner 1y agoWhat about the ones you can recover from? You don't want to crash the entire application every time there's an exception!
- Kwpolska 1y agoYou usually wouldn’t crash the entire application, the request that causes the issue will return a 500 error. (Or equivalents for non-web environments.)
- breadwinner 1y agoSome exceptions are not recoverable and may cause 500 error. Others such as FileNotFound are recoverable, for example by reading the file from an alternate location.
- mrkeen 1y ago> You have no compiler-enforced way to know what exceptions might be thrown from a method or library. Always assume exceptions will be thrown from a method or library.
- breadwinner 1y agoWhich ones? That's the issue.