Article:		Exception-Handling Antipatterns
Subject:		Completely disagree, whole heartedly!!!
Date:		2007-12-15 15:25:16
From:		colin_saxton
I think that all exceptions should be runtime exceptions because they are exceptional!! You shouldn't force anyone outside of your API to catch and deal with an exception...it should be up to you to deal with them.. If you get an IOException in your API then you should catch it and deal with it...If you have no other options to deal with the IO problem then you should throw a runtime exception because it most likely means that there Harddrive in on the way out or there modem is not connected...etc...etc. HOWEVER....Most of the time you can't do anything anyway...so you catch the exception and throw it...MAKE IT A RUNTIME because no one else is going to be able to do anything with neither so it ***NEEDS TO FAIL*** the application and it will give you a stacktrace so that the developer can deal with it... 1. Exceptions slow down code! 2. Forcing developers to handle the exception also means you get completely irrelevant try catches all over the place... *** About 99% of the time they just catch your exception and throw it with your exception message attached to it (what is the point of that!!!???). Cluttered code!*** 3. Throwing a runtime exception means that a developer using your API can choose whether or not to deal with the Exception...they may be able to do something AND (AND!!!) they have a choice!? 4. I use C/C++ and the number 1 (absolute number 1) pain in the ar$e problem with java is the amount of forced exception handling code that gets rammed at you. All exceptions should be runtime exceptions...show me some *real* code that benefits from caught exceptions instead of caught exceptions (show me some that you have done and is out there and can be looked at) ;)