Can Checked Exceptions be thrown at Runtime?

[Santosh Kumar Nayak]

ClassNotFoundException is a Checked Exception

But this exception is thrown at runtime.

Can Checked Exceptions be thrown at Runtime ?  

[Dave Tolls]

All exceptions are thrown at runtime.

[Paul Clapham]

And exceptions are only thrown at runtime.

[Campbell Ritchie]

Ken Kousen in his book which he was promoting a few months ago says that RuntimeException is the worst named class ever (or similar). The name makes people think it is the only sort of exception thrown at runtime. Of course, if you get people going on about compile‑time exceptions when they mean compile‑errors, that doesn't help.

[Scott Shipp]

Wow! I never even thought of the naming of RuntimeException. That's pretty funny!

[Tim Holloway]

Wow. That's right. A more accurate name would have been "UncheckedException". Although IIRC you can specify a RuntimeException explicitly as checked - it's just that if you don't, the compiler won't flag it as an error.

I'm guessing that the people who named RuntimeException were the compiler writers and they were thinking in terms of what should be legal to compile, but it's definitely one to puzzle over.

[Campbell Ritchie]

Tim Holloway wrote:. . . . you can specify a RuntimeException explicitly as checked . . . .

How do you do that? I have tried that sort of thing and never succeeded. I don't know enough C++ but I heard somewhere that a C++ exception behaves like a checked exception if it is dcelared as possibly thrown, and unchecked if it is not so declared.

the people who named RuntimeException . . .

The theory, I have read somewhere, is that a runtime exception is thrown because of an occurrence entirely inside the runtime and a checked exception is thrown because of an occurrence at least partially outside the runtime. Now tell me how something like InputMismatchException and InterruptedException fit into those categories.
As I said, that is the theory. I am by no means convinced I believe it.
The theory is that something occurring inside the runtime cannot be corrected without stopping the app and altering the code, and something at the interface between the runtime and the big wide world can be corrected. I can believe that for an IOException caused by a poor network connection which can be reconnected, but not convinced about every other cause.

[Tim Holloway]

Replying in reverse order: I'm not sure what they defined "runtime" as, since I consider it anything happening in the execution-time JVM (as opposed to the compiler JVM). Perhaps they meant "core" JVM, but that's a region that isn't very precisely defined.

On declaring a RuntimeException as checked, I'm pretty sure you can define a method like this:

void doSomething throws SQLException, WebServiceException {
....
}

Even though WebServiceException is a RuntimeException and therefore can be thrown unchecked. It really serves only as documentation, since I don't think the explicit check on WebServiceException is propagated out as mandatory the way the SQLException check would be. Which, come to think of it, does imply some internal housekeeping differences at compile time. So, if one contorts oneself enough could be interpreted as meaning that a RTE is "source-checked" only at runtime.

[Campbell Ritchie]

Things like network connections and the hard drive are outside the JVM and therefore part of the computer or big wide World, not the runtime.
I don't like the idea of declaring an unchecked exception in a throws. I think it belongs in the documentation comments, however.

[Tim Holloway]

Well, unless you go native, networking, disk, and other peripherals are only dealt with via java virtual equivalents, so I'd be hard-pressed to consider that as a factor.

I'm going on fuzzy visualizations of what I'd have to do to support checked and unchecked exceptions in compiling and runtime, and while I'm not certain, I suspect that the language environment almost has to allow explicit declaration on unchecked exceptions - at least unless you added some kinkiness to the process. And I could make a case for a language definition that required a caller seeing an explicit unchecked declaration to require handling it in the calling routine (essentially making a temporary override to the "unchecked" attribute). Though that part might get troublesome one you started dealing with external libraries.

I do like to javadoc unchecked exceptions if I expect the caller to handle them, regardless of whether I'd explicitly declare them in the method header or not.

[Campbell Ritchie]

Tim Holloway wrote:. . . a language definition that required a caller seeing an explicit unchecked declaration to require handling it in the calling routine . . .

. . . sounds a good idea. . . . But I don't think it exists in Java®.
I agree with you: the definition of runtime exceptions is fuzzy.

[Jack Ramon]

It may or may not be okay, depending on the context, but it probably is not.

As a rule of thumb RuntimeExceptions should only be used to indicate programming errors (examples include IllegalArgumentException and IllegalStateException). They don't have to be checked exceptions because you generally assume your program is correct until proven otherwise and you cannot handle these exceptions in a meaningful manner (you have to release an updated version of the program).

Another valid use of runtime exceptions is when you use a framework that will catch and handle the exception for you. In such a scenario it would only be burdensome to having to declare the exception in every method when you are not going to handle it anyway.

So generally speaking I would say re-throwing a checked exception as a runtime exception is very bad practice unless you have a framework that will handle it properly.

[Campbell Ritchie]

JR: Welcome to the Ranch

Good points there, so I shall ask you this:-

If a framework catches the exceptions for you, does that make them easier or harder to handle? I had some problems trying to learn JavaFX. The example in the tutorial book said to open some sound files; failing to open the files will cause an exception to be thrown. Unfortunately the framework catches the exception and simply prints a really helpful error message reading something like, “Unable to open file XXX.”