Re: In development yes

Post #143,649 by JimWeirich 2/27/04 12:35:18 PM Reply	Re: In development yes The point is that you want ot handle these differently because they represent programming errors and you don't want to miss them. There are a lot of programming errors that I don't want to miss, but not all of them (by any stretch of the imagination) are represented by RuntimeExceptions. If I misspell the table name in an SQL statement, that's a programmer error too, but an SQLException is not a Runtime Exception. It seems very artificial to say Checked Exceptions should be caught and Uncheck exceptions should not be caught. If I call function f() and it fails, I don't really care if it failed because a null pointer was dereferenced or a file couldn't be openned. Furthermore, there is a significant number of programmers who consider checked exceptions a language wart and are moving to unchecked exceptions (witness Scott's response in this thread). -- -- Jim Weirich jweirich@one.net [link\|http://onestepback.org\|http://onestepback.org] --------------------------------------------------------------------- "Beware of bugs in the above code; I have only proved it correct, not tried it." -- Donald Knuth (in a memo to Peter van Emde Boas)
Post #143,882 by bluke 2/29/04 1:25:04 AM Reply	Agreed which is why you should not just catch Exception, you end up swallowing more then you can chew. I agree that checked exceptions are a bad idea. They end up polluting the code with a lot if extraneous code. Unfortuntely, Java forces you to handle checked exceptions.
Post #143,931 by CRConrad 2/29/04 4:03:57 PM Reply	So wouldn't the remedy be... BLuke cautions and laments: which is why you should not just catch Exception, you end up swallowing more then you can chew. I agree that checked exceptions are a bad idea. They end up polluting the code with a lot if extraneous code. Solution: Use only unchecked ones; i.e, make all your own ones descend from RuntimeException (or whatever the name was). Unfortuntely, Java forces you to handle checked exceptions. Hmm... So how about, in stead of wrapping and re-throwing every exception "ten times" (cf your comment in another sub-thread), you'd catch all checked exceptions that you have to handle, on the lowest level where they occur, and wrap and re-throw them -- once and once only, wrapped in one of your own RuntimeException-descended ones? That's the best way I can see of handling a bad situation you can't really change; at least then you won't have to screw around with your intervening layers on each change at a higher or lower level. Right? [link\|mailto:MyUserId@MyISP.CountryCode\|Christian R. Conrad] (I live in Finland, and my e-mail in-box is at the Saunalahti company.) You know you're doing good work when you get flamed by an idiot. -- [link\|http://www.theregister.co.uk/content/35/34218.html\|Andrew Wittbrodt]
Post #143,933 by admin 2/29/04 4:51:06 PM Reply	cf. Spring Framework :-) Regards, -scott anderson "Welcome to Rivendell, Mr. Anderson..."
Post #143,961 by bluke 3/1/04 5:36:33 AM Reply	I agree ... the problem is convincing everyone else. Most people still believe in the checked exception mantra. What makes it worse is that the Java libraries use checked exceptions all over the place.

Welcome to IWETHEY!