@slashkev said:
- checked exceptions - this was a last minute change introduced by Bill Joy right before Java 1.0 went out the door - and has created some of the biggest coding nightmares i have ever seen. i have never seen more catch/warp/retrow coding in my entire life. when a company says their app is 50k lines of code - rest assured that 50% of that is dealing with the poorly thought out nature of checked exceptions. better yet, most of the open source java code i have seen simply catches exceptions, prints the stack trace to stderr, and continues.
yes, 1 or 2 influential guys at sun think something is important, and you will be forced to live with the consequences for the next few decades.
I know it's currently fashionable to have a go at checked exceptions, so I'll forgive you for bowing to the norm. But I still think checked exceptions are a great thing, when handled correctly. I'll agree - I've seen plenty of code where I've created a new Foobar() only to have to catch 5 or 6 different types of exception, but just because people use the exception hierachy badly doesn't in itself make it a bad concept.
It's my belief that exceptions should only be thrown if the calling code can *do* something about it - retry, shut things down, try something else, etc. Otherwise the exception can, most of the time, be catagorised as a minor exception (and should be properly logged and recorded and not thrown up to the calling tier) or a severe exception (which should probably be converted into a Runtime exception which shuts the application down). The severe exceptions should, as much as possible, be detected at start-up or on first instantiation. Frameworks like Spring gear themselves towards this.
In essence, I'd still prefer an exception hierachy which allows (or forces) you to pick your level of granularity rather than one which requires little or no explicit exception handling.