Comments on: Voting for Checked Exceptions

By: pp

pp — Thu, 11 Feb 2010 16:24:20 +0000

HI,

Nice comments… we must begin with “an error is an error” in any language, waht can be done whe someone delete alll records in a table ? mmm … Maybe another confussion is that in Java some programmesr trend to use them as an business validation .. I mean, some one uses “throw exception” to inform that the password was wrong …..

Uses checked or unchecked exceptions don’t guarantee that you have a robust application .. we are human, we make mistake. Using cehcked exception tell us what we must not forget… but … I watched a lot of code with try{ … }catch(Exception e){ null; } (senior java, maybe a little tired) … trying to prevent to manage the error … It’s no nice, it is better let’s flows the real error.

I repeat we are not working with geniouses we work with real guys, with personal problems and another issues, our mission it’s to help them,,.. My position, I really hate to use checked exception … I repeat, an error is an error no way treat with them ..

I don’t know, how much experience has Harold with other language (C, ADA, Lips, Cobol) and building real applications?, where you must be “quick” and go live soon as posible, when you must fight wiht legacy code …. to use a checked exception and don’t forget to catch every error in the system could be a nightmare code ?? I think (with respect), Harol is a great theorical guy, who can teach and write great books..

With Respect.

By: Elliotte Rusty Harold

Elliotte Rusty Harold — Tue, 18 Aug 2009 19:54:38 +0000

MalformedURLException is a checked exception because it reflects whether the running VM has the right protocol handler installed. One VM can throw a MalformedURLException for a URL for which another VM won’t. There is no way to guarantee at compile whether the code that constructs a java.net.URL will or will not throw an exception.

SQLException is a checked exception because the SQL string is evaluated by the database server (or the JDBC driver), and different servers accept different dialects of SQL. Again, you can’t tell at compile time whether the exception will or will not occur. Therefore SQLException is properly a checked exception.

URISyntaxException is one Sun got wrong. It should be a runtime exception because it doesn’t depend on the environment in which it executes and it can be verified at compile time. Basically it’s a type of IllegalArgumentException like NumberFormatException. However, it isn’t. It’s a checked exception. That’s simply a mistake.

By: constv

constv — Tue, 18 Aug 2009 19:26:00 +0000

“With that being sad I do not see checked exceptions being taken away from Java anytime soon as it would clash millions of lines of code.”

I am not so sure. If the Exception class is re-factored to become “unchecked”, the existing code (that now successfully compiles) should still continue to work in the same manner. It’s just that billions of lines of today’s code that are wasted on catching and re-throwing will become redundant (in those cases when the programmer is indeed trying to properly propagate a checked exception instead of mishandling it way before it reaches the place where it should and can be properly handled.)

Also, here’s the more accurate link to the article I mentioned in the previous post:
http://constv.blogspot.com/2009/08/error-handling-and-exceptions-in-java.html

By: constv

constv — Tue, 18 Aug 2009 19:14:41 +0000

The author expresses a very strong opinion – specifically, stating that anyone who is against checked exceptions doesn’t understand the difference between checked and unchecked, but states that he doesn’t have time to explain that very difference. Instead, as many checked exception zealots, he hides behind a book by a respectable author. In other words, “checked exceptions may not be a bad idea because the authors of Java said that they are good, and who are we to argue with the Gods?” (By the way, the newer specs from Sun, such as EJB 3.x, DO NOT contain checked exceptions. Need any more hints?) The opinion is based on the lack of understanding of what exceptions (the original concept!) are for, in the first place. Checked exceptions are, perhaps, the worst and the most dangerous feature ever introduced in a programming language. I have never – I mean, ever! – seen checked exceptions being used properly. They always introduce chaos and cause essential error information to be lost. It is much easier to design clean and reliable error handling with runtime exceptions only than to ensure the correct propagation and handling of checked exceptions. The sad reality is that it has become an EGO issue for those cocky programmers and architects who have failed to see the flaws of checked exceptions for years, and now are getting ticked off by other people pointing at it. For most such people it;s just a matter of pride and unwillingness to admit that they used to do it the wrong way. I have been programming in Java for over 10 years, and originally had bought into the checked hype. It took me some time (as well as some excellent advice/insight from a brilliant co-worker) to see the truth for myself, and to admit that I had been missing the point. Amazingly, it doesn’t take much to make perfect sense of exceptions (and I mean UNchecked ones.) I have written an article on the subject where I honestly attempted to analyze the role of exceptions in error handling, the difference between checked and unchecked exceptions, and the benefits (if any) and flaws of the “checked” concept. The article can be found here:

http://constv.blogspot.com/

Hope that helps someone.

By: rrr

rrr — Mon, 17 Aug 2009 23:57:05 +0000

With that being sad I do not see checked exceptions being taken away from Java anytime soon as it would clash millions of lines of code.

By: rrr

rrr — Mon, 17 Aug 2009 23:52:54 +0000

An author is wrong. Checked exceptions do NOT disambiguate between external situations that programmer has no influence upon and obvious programming bugs that should never happen in the first place. As example take SQLException: it’s one case when sql server is down/has maximum number of connections exceeded/we, but it’s completely different if it’s up and running and we try to insert sloppily generated data that infringe FK constraints. Or take getting website’s source code by URL: it’s one case when server/DNS is down or you lost your internet connection, but how about passing malformed URL to the method?

This makes checked exceptions dangerous as one may assume that it’s handled, so this piece of code can cause no bugs. As it turns out URL is malformed or data is generated the wrong way, you get exception, you handle it as if it was sth external and forget about it. You think this is the right approach?

By: John

John — Mon, 20 Apr 2009 21:01:28 +0000

I know this is an old topic, but it’s still one of interest.

Checked exceptions are good.

The only complaint I’ve found interesting is what to do if I need to include another checked exception as part of the method signature?

Really, there’s only a handful of solutions:
1. Break compatibility (rarely a viable for commercial APIs)
2. Subclass one of the already declared exceptions–provided it really is a meaningful suclass–and preserve the method signature (least evil approach).
3. Throw the exception as an unchecked exception.

#3 is what we’d get anyway, if Java were to dispense with unchecked exceptions.

#2 Requires good exception design from day one. The problem is that most API writers slap together exceptions as an after-thought, rather than making it a part of the design from the get-go. You want your base exception classes to be meaningful, but not so specific that you trap yourself later (easier said than done).

It’s still not ideal, since I don’t have an auto-documented way of knowing exactly what subclass may be thrown by the method. But imho, it’s still quite viable.

By: ralph

ralph — Thu, 03 Jul 2008 19:05:13 +0000

I wrote a service/daemon which scans several web sites, processes their content and uploads results into the database. Obviously it is supposed to be entirely transparent to the end user – no messages that something is wrong, it must try until it succeeds. So, various things can go wrong – database may be down, server may be unreachable, etc. But it doesn’t care AT ALL, what’s wrong – it’s sufficient to know that SOMETHING went wrong to try again shortly. So, what’s the point of checked exceptions here?

Regards

By: Elliotte Rusty Harold

Elliotte Rusty Harold — Fri, 30 May 2008 13:06:20 +0000

Bruce at least has backed way off from that position, to the extent that he ever held it at all. The problem arises not from checked exceptions, but from using checked exceptions where runtime exceptions are appropriate. Using nothing but checked exceptions would indeed be atrocious. Fortunately that's never been necessary, and hasn't even been all that common for the last six years or so (since Effective Java came out). The "orthodox" position is not what you seem to think it is. Using nothing but checked exceptions has never been the orthodox position, though it's perhaps been parodied that way by developers who still don't want to spend time on error handling, with checked exceptions or otherwise.

By: Eric Herman

Eric Herman — Thu, 29 May 2008 21:56:06 +0000

2004 IBM “Java theory and practice” quote in-escapable:

Recently, several well-regarded experts, including Bruce Eckel
and Rod Johnson, have publicly stated that while they initially
agreed completely with the orthodox position on checked
exceptions, they’ve concluded that exclusive use of checked
exceptions is not as good an idea as it appeared at first, and
that checked exceptions have become a significant source of
problems for many large projects.

http://www.ibm.com/developerworks/java/library/j-jtp05254.html

http://www.tiedyedfreaks.org/eric/CheckedExceptions.xhtml