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.
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.
Tim Holloway wrote:. . . . you can specify a RuntimeException explicitly as checked . . . .
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.
the people who named RuntimeException . . .
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.
On declaring a RuntimeException as checked, I'm pretty sure you can define a method like this:
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.
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.
. . . sounds a good idea. . . . But I don't think it exists in Java®.
Tim Holloway wrote:. . . a language definition that required a caller seeing an explicit unchecked declaration to require handling it in the calling routine . . .
I agree with you: the definition of runtime exceptions is fuzzy.
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.
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.”