4 ms·
Unfortunately, mediocre developers are perfectly capable of learning to either catch and silently ignore checked exceptions (checked exceptions actually promote
by dm3 13y ago
Unfortunately, mediocre developers are perfectly capable of learning to either catch and silently ignore checked exceptions (checked exceptions actually promote this habit, which can be successfully used in other languages with exceptions) or rethrow them as runtime exceptions.
The good thing is - newer java libraries use unchecked exceptions in the vast majority of their APIs.
- bjhoops1 13y agoWhen I come across exceptions that get silently "eaten" I want to throw the dev out of a window. I've lost days of my life tracking down inscrutable bugs only to find something like this: catch ( Exception e ) { /eat it/ }
- cjg 13y agoThat's not a good thing when you are trying to write absolutely bullet-proof code that will not fall over and can recover / retry robustly. A desktop top app is a good example of this. Network connection gone, disk full, file missing, etc. These things should not be fatal. Once the user gets back within WiFi range, empties their recycle bin, or plugs in some external storage device, the code should be able to continue sensibly. In this situation, handling RuntimeExceptions at a high level loses all the context. Whereas, remembering to handle all the RuntimeExceptions every time you make a call is silly - they should be checked exceptions then the compiler can warn you. I've ended up wrapping a Java library to make sure that I got checked exceptions to avoid this problem. Of course, some methods in Java throw checked exceptions some throw RuntimeExceptions. Most of these choices are sensible, but sometimes you have a hard-coded URL and you know it's not malformed. But equally, sometimes you have to catch a specific RuntimeException because that is a situation that you want to handle.