Hi Anna,
Unfortunately, I cannot remember where I saw this description but I liked it and trying to follow it ever since:
RuntimeException and its subclasses are caused by bugs in a program. On the other hand, checked exceptions can occur in a fully de-bugged (no such animal, I know) program because of circumstances beyond control of the program (and the programmers).
Now, let me elaborate on it a bit.
For example, situations that might cause runtime exceptions such as NullPointerException, IndexOutOfBoundException, ArithmeticException etc. can be foreseen and prevented by a programmer and, generally speaking, will never occur in a high-quality program. Runtime exceptions are data-dependant and repeatable � you can reproduce them with the same set of data. When user enters a letter instead of a number and the program tries to convert it to a numeric type � it can be foreseen, and it is a bug, if it was not. That�s why NumberFormatException is created as a runtime exception. If runtime exceptions do occur, we want to know about them as soon as possible and as close to the source as possible in order to fix the program: you can log them, send them on pager etc. but runtime exceptions must never be ignored. What to do with the program when RuntimeException occurs really depends on what happened and how critical the problem is. Most likely, it is critical and it will be very hard, if not impossible, to restore the normal flow since the exception was caused by something that was missed in the first place. (Of course, you could catch NumberFormatException and tell the user to enter a number. But this is really bad programming practice.) So, it is fully acceptable to simply shutdown the program though as gracefully as possible - saving data (if it is guaranteed they are not corrupted), closing files, etc. and get programmers to fix their problems.
Checked exceptions can happen at any time, cannot be prevented and therefore the language enforces to deal with them. Declaring a method to throw a checked exception is creating the contract that says �I cannot guarantee that I will not fail, so don�t count on me�, so you are forced to have a plan �B�.(And, by the way, it is not unintentionally that this contract cannot be changed by subclassing). One thing that, I guess, is fair to say about checked exceptions that they mostly caused by interaction of the program with the external world � operating system, other programs, network etc. Other characteristics of checked exceptions are that they are time-dependant and not-repeatable.
You cannot predict a time when the server will be shutdown. Before
Java, (and C++ of course) it was a common and usual practice to signal about a problem by the return value. If we were to create this program in C, for example, then you would say that when lock method returns �1, then its execution was abnormal. But checking the return value cannot be enforced in C and it is a general source of problems. So, authors of Java have created checked exceptions to eliminate that sort of problems. When you declare your lock method to throw a checked exception, you enforce a client programmer to consider the case when he cannot obtain a lock by circumstances out of her/his control. Declaring lock to throw a runtime exception will leave it up to client programmers and I believe would be wrong. (On this project it is the same programmer but why to make somebody so special?
)
I am gonna stop now � it�s got too lengthy
. But hope it helps.
Best regards,
Vitali.
BTW, I liked your postings in this
thread:
Topic: Lock on reading records It helped me see that it is not only me realising the issue and that it is in fact is a problem.
I tried to find answers to the similar concerns here:
Topic: single raf vs. raf per client