I’ve had the unpleasant experience of trying to help someone debug some Java code. We had a stack trace, and it pointed to a line where a new exception was being thrown within a catch block. So all that’s needed is to look at the try block and figure out where it was throwing the original exception, right? Only problem: the try block is 140 lines long.
Why would someone do something like this? Well, beyond not really understanding the importance of modularization, undoubtably the reason was to work around one of Java’s features: in a method’s signature you have to declare all the exceptions it might throw. So he (I know who the guilty party is; that”s the correct pronoun) wrapped everything in a try block and threw his own exception so the compiler would accept his code. The reasoning behind this feature is clear, they’re trying to force programmers to think about what errors might occur and how they should deal with them. But of course you can’t really force someone to think if he doesn’t want to; people will just do something goofy to subvert your restrictions.
Well, based on some code I’ve been looking at recently, the other common solution is just to declare that your method throws “Exception”, which also completely subverts Java’s design intent.
But the absurdity of Java’s exception specification system is obvious when you look at how servlets work, “nesting” type-checked exceptions inside specified “servlet exceptions”. It’s just hard to write infrastructure with specified exception lists without resorting to such things.