You should know about it, sure - but that doesn't necessarily mean you should be forced to declare-or-handle the exception in all calling methods. In many cases I'm perfectly happy just letting the exception be thrown - it can stop the program, OK, and I'll get a nice clear error message then. If more robustness is required, I will insert catch blocks at strategic places, usually including a few catch blocks for RuntimeException, Exception, or even Throwable. Because there are enough other things that can go wrong that are represented with runtime exceptions, including some that are not just programmer error. So I'm not going to assume that I should only worry about checked exceptions. Anyway, I'm definitely going to know about any exception that occurs. The question is just what level it gets handled at.
This would greatly simply these APIs as really these are truly runtime exceptions and do not normally need to be checked for.
I don't believe this would break existing applications as you can declare RuntimeExceptions in throws clauses.
Unfortunately this can break existing applications. Consider:
This code is perfectly legal in Java currently. Maybe not common, or a good idea, but it's legal, and something like it probably exists in at least some programs currently operating in businesses. If we redefine IOException to be a RuntimeException, then this would get an unreachable code error, as there's no way that catch IOException will ever be reached. Fixing this would require further changes, like loosening the rules of unreachable code. I don't see Sun doing anything like this in the forseeable future.
This sort of change is really only going to occur in a Java-based successor language like, say, Scala, which as a matter of fact does not have checked exceptions. (Like pretty much every other language I know of, save Java.) I think the notion of checked exceptions is too deeply ingrained into the Java community in general, even though there are also plenty of people now who oppose checked exceptions. For further thoughts on related matters, check out Is The Java Language Dying?
"I'm not back." - Bill Harding, Twister
Joined: Feb 22, 2004
@ Ernest You will know about it as Jim says. It's just that 90% of the time you really just want to throw it so why have all kinds of checking around it?
What I mean about domain level is that checked exceptions are best used in your business domain. They are less useful as general exceptions.
This kind of checked exception is very useful as it clearly documents the domain level exceptional circumstances that the method will not handle. This is what's lacking in other languages such as scala and c#.
My point is that all these general checked exceptions pollute the real use which should be for domain only.
Yes, I agree that it could break apps in some edge cases. I think Sun should not bother changing anything for unreachable code. Realistically, these issues would be few and far between and easy to fix in code.
Checked exceptions are important and useful as they inform about some exceptional scenario that can occur in underlying component which is not handled within it. Component owner forces client to handle those scenario as component owner feels it is important. Where as 90% what we talk of simply bubbling up exception or dumping stack trace and ignoring it is a bad practice. Those 90% are your test programs where as 10% are professional industry code that handle this exceptions correctly.
Joined: Jan 30, 2000
[Gladwin]: Where as 90% what we talk of simply bubbling up exception or dumping stack trace and ignoring it is a bad practice.
"and ignoring it" would certainly be bad practice. I definitely don't advocate that.
[Gladwin]: Those 90% are your test programs where as 10% are professional industry code that handle this exceptions correctly.
That breakdown sounds rather simplistic to me. There's more to the world that test programs and "real" code which must be absolutely error-free. Check out Joel Spolsky's Five Worlds for a somewhat wider (not necessarily complete) perspective. Personally I've worked on a number of internal company projects where the customer is not so concerned with presenting a robust front to the user - instead, they were concerned with detecting an error promptly and then having someone fix it. The customer valued development speed over robustness of the final product. That's not uncommon in some environments. If that's what the customer wants, fine. Code written for such customers is not test code, and can be every bit as professional as code for other projects. It just has different priorities.
Moreover, even if you're on a project where robustness is a priority, it's often not enough to just consider checked exceptions. There are plenty of unchecked exceptions with underlying causes that a programmer needs to consider - what if a given value is null? Or zero (and you're planning to divide by it)? Checked exceptions don't really help you here. Careful testing does - but even with plenty of testing, I think it's important to consider what if there's something you've missed? What if there's some input you've overlooked that will create a NullPointerException or NumberFormatException or ArithmeticException? Which often means you need to identify some strategic points to catch these unknown RuntimeExceptions (or maybe even Errors) and do something about them. This is true whether you like the concept of checked exceptions or not. For robustness, unchecked exceptions can't be overlooked, and as long as that's the case, how much benefit are you really getting from the checked exceptions?
I don't deny that there are situations where having checked exceptions reminds a programmer to handle something they might otherwise have overlooked. But I've also seen plenty of cases where they encourage younger programmers to hide errors or to attempt to handle the problem at a lower level than is really appropriate. As a result I have serious doubts about the net benefit of checked exceptions in Java programming.