About Question enthuware.ocajp.i.v8.2.1412 :

[blackdraft]

What does " external to an application" mean? Sounds like exceptions being cast by dependency's like accessing a file or opening a socket? is that correct? This does mean that the exception itself is casted in the application itself right?

[admin]

It means anything that is not part of your application. For example, your application may interact with file system. The file system is part of the OS. The file system is not part of your application but your application uses it/interacts with it.

HTH,
Paul.

[Kevin30]

In the explanation it is stated "If a client cannot do anything to recover from the exception, make it an unchecked exception".
If you have an unchecked exception, for example an Arithmetic exception, you CAN easily recover from the exception: just put a try-catch around the code.
So I don't see how an unchecked exception is something that you cannot do anything to recover from.
Can you please clarify? I think I'm missing something here.

[admin]

There are multiple things to understand here. First is that there is a distinction between a component (or a program or routine) and a user of that component (which is also another component). For example, there could be a component that takes a filename, opens that file, and returns the content of that file as a String (lets call it component 1) and another component (component 2) that makes use of this component 1. Now, what if component 2 passes some file name to component 1 which does not exist? Component 1 will probably get a FileNotFoundException while opening that file can certainly catch that exception. But what will it do after catching that exception? It cannot generate the data, right? That means, catching an exception in itself doesn't mean "recovery" if there is no proper course of action after catching the exception. Thus, the right course of action here would be to let the exception propagate to the caller.

The caller, on the other hand, could be a UI program. It can catch the exception and show a message to the user and make the user select another file. This is what is meant by "recovery" from an exceptional situation. It makes sense for the UI component to catch the exception because it can recover from it.

Now, coming to the explanation that you've mentioned, it is not saying that if you get an unchecked exception you cannot recover from it. It is saying that if you encounter a situation from which you cannot recover, it is ok to throw a runtime exception to the caller.

If a problem can be foreseen while designing your component, you should declare that problem as a checked exception in method signature (for example, FileNotFoundException), otherwise, it is ok to throw an unchecked i.e. a run time exception, which need to not be declared in the throws clause.

[Kevin30]

Thank you very much for your elaborate response!

I think I understand when you have to throw an checked exception and what is meant by "recovery" for an exceptional situation. In the example you give with a FileNotFoundException, that would be a "recovery" for an checked exception as you say. OK, so much for checked exceptions.

Now moving on to Runtime exceptions.

You state:

Now, coming to the explanation that you've mentioned, it is not saying that if you get an unchecked exception you cannot recover from it. It is saying that if you encounter a situation from which you cannot recover, it is ok to throw a runtime exception to the caller.

Below, I've marked my 3 most important sentences with A), B) and C).

What I don't really understand is:
A)
If you want to throw a Runtime exception, WHEN do you (as you say) "encounter a situation from which you CANNOT recover"?
To me it seems that this never happens, or at least almost never happens.

B)
And I also don't understand WHICH Runtime exceptions would be thrown when you "encounter a situation from which you CANNOT recover"?
I mean, you can easily "recover" from Runtime exceptions such as a NullPointer-, an ArrayIndexOutOfBounds, an Arithmetic- or a ClassCastException by using a try-catch. Admittedly, these Runtime exceptions are thrown by the JVM. But Runtime exceptions thrown by the programmer such as an IllegalArgument- or IllegalStateException can also be "recovered" with a try-catch, can they not? So which Runtime exceptions are we talking about that can be thrown when you "encounter a situation from which you cannot recover"?

By the way, I think you CAN foresee Runtime exceptions as well, you just have to take the time to examine your code more thoroughly.

A handicap for my understanding of the subject is - I think - that I've no real programming experience apart from writing hundreds of really small programs to test out code and studying hard for the Java OCA SE 7 exam. But I've thoroughly read and thought about the explanation, your answer, the link you provided plus several other documents on the subject, and on that basis my solution now for Runtime exceptions is the following:

C)
You CAN easily "recover" from most if not all Runtime exceptions with a try-catch (and you CAN foresee them as well),
BUT it is not REASONABLY expected of you to do so because Runtime exceptions are the result of an internal / programming problems. Therefore, if you encounter a Runtime exception you can best correct the programming mistake instead of putting a try-catch around it.
Furthermore, Runtime exceptions in a typical program are numerous so catching all of them would (drastically) reduce the clarity of your code.
These are the 2 reasons why you cannot be REASONABLY be expected to catch Runtime exceptions.

Am I correct in my assessment of Runtime exceptions?

Thank you in advance!

[admin]

You CAN easily "recover" from most if not all Runtime exceptions with a try-catch (and you CAN foresee them as well),

Recovery and what constitutes recovery is a decision taken by the developer. So whether it is easy to recover from a situation or not, is something that only the business logic of the method/routine can drive.

Try/catch is one mechanism that you can use to recover from a situation. (Using multiple "if/else" statements is another way to recover).

The point is that if you, as the developer of the method, believe that you can recover from a situation then you should not throw an exception to the caller of the method. The question and the associated explanation is about the situation when you know that you cannot recover from a situation.

Remember that "recovery" is a higher level concept than merely catching an exception.

[Kevin30]

Thank you for your response and your patience!

Recovery and what constitutes recovery is a decision taken by the developer. So whether it is easy to recover from a situation or not, is something that only the business logic of the method/routine can drive.

and

Remember that "recovery" is a higher level concept than merely catching an exception.

OK, got it! So recovery isn't a technical issue, but a decision that is taken. I assume then that I was not wrong in my interpretation of a Runtime exception. Thank you.

The point is that if you, as the developer of the method, believe that you can recover from a situation then you should not throw an exception to the caller of the method.

OK, it think I got this too. So this means that if the business logic of the method/routine demands that the situation should be recovered, which is the case with checked exceptions, you should not throw the exception but catch it. Correct?

The only thing left that is - I think - not entirely accurate is:

The question and the associated explanation is about the situation when you know that you cannot recover from a situation.

The question is about checked exceptions, which is defined as exceptional conditions external to an application that a well-written program should anticipate and from which it can recover.
The associated explanation covered both checked and unchecked exceptions.

[admin]

So this means that if the business logic of the method/routine demands that the situation should be recovered, which is the case with checked exceptions, you should not throw the exception but catch it. Correct?

This is the part where an accurate yes or no answer is not possible. What about a middle layer component A that makes a call to another component B in a lower layer, and that component throws a checked exception from which A cannot recover logically?

This is a very debatable issue and there are equally strong views on both sides. So much so that languages such as c# consider checked exceptions totally useless.

I would suggest you to follow the link given in the explanation and stick to it for the purpose of the exam.

Paul.

[Kevin30]

I'll do that. I think I'm a lot wiser now on the subject. Thank you.