Runtime exception for other than programming error.

Question

In a conversation the question arose whether it could be a case of throwing a runtime exception for anything other than a bug. The tutorial on oracle site says "These Usually Indicate programming bugs" leading to think that can be used in situations in which there is no bug.
Anyone have a practical example of a runtime exception when there is no bug?
Thanks.

Answer 1

937643 wrote:
Ok. But. Do you think that in these cases the use of a runtime exception could be considered a bad practice?That's actually a matter of some debate.
On the one hand, Java has defined two major kinds of exceptions since the very beginning (unchecked exceptions, which are RuntimeException, Error, and their descendants; and checked exceptions which are everything else). The intended use of those was that checked exceptions should be for things that can normally go wrong in the execution of a program, even without a bug or without a major internal JVM error, such as a failed attempt to persist something or a network connection dropping--stuff that a programmer might normally be expected to deal with; while unchecked exceptions were created for things that a programmer would not normally handle in his code (except possibly at major architectural boundaries), like buggy code or an internal JVM failure.
With the rule about having to catch or declare checked exceptions, but not unchecked ones, that makes it easy for programmers so say, "Okay, I know exactly what can go wrong here that I might be expected to handle and I can therefore choose what to do with it; there will be no surprises. But I don't have to deal with problems that are outside my normal responsibility, like somebody passing me a null when they shouldn't have." It gives a programmer a nice bit of control, and the ability to know he hasn't missed something, kind of like the type safety provided by a strongly typed language.
At least that's the theory.
In practice, most checked exceptions either just get bubbled up to the next layer (via a throws clause), or caught wrapped in a fairly generic layer-appropriate exception and rethrown. There's not a whole lot of use made of what checked exceptions provide, and there's a lot of ugly boilerplate code that doesn't do anything useful for the app but is just there to satisfy the compiler.
So, some people think that checked exceptions are useless, or mostly useless, and favor unchecked exceptions in most or all cases. I believe that's part of the philosophy of Spring, but I'm not totally sure.
The idea is that since most of the time you can't do anything about exceptions that might be thrown to you, it's wasteful and pointless to have all that code to catch and rethrow. In this viewpoint, it would be better if, for example, not providing a throws clause at all meant that you could throw any exception. Any given code can still catch specific exceptions that it knows it can handle, but we don't have to write a bunch of code notating something that we're not really doing anything about.
Personally, I used to be totally in the checked exception camp. However, all the pointless boilerplate is wearing me down. I'm still not completely convinced though, and here's why: If I'm calling a method, I'd like to at least be able to see what might go wrong, so that I can decide how to deal with it. If all exceptions were unchecked, and the throws clause were optional, a conscientious developer could still provide it, and list the unchecked exceptions his method might throw to me, and/or he could document them in the javadoc comments. But a lot of developers won't do that, or even if they start to, as their method evolves, without the compiler to enforce it, they won't keep it up to date.
So there are advantages to both approaches. I personally would to know that the information will always be available to me, but for the small percentage of the time where I actually use it (like handle one specific exception one way and some other exception differently), I'm not sure if it's worth the overhead.