About Question enthuware.ocpjp.v7.2.1381 :

[jklb]

Could you explain why "A exception thrown by a failed assertion cannot be caught by a try/catch block" is not correct? I know that an AssertionError is thrown if an assertion fails and will not be caught, and I also consider an AssertionError to be an exception (small e). So I assumed this was the correct answer.

Is the issue the semantics of calling an AssertionError an exception?

[admin]

Because it can be caught by a try/catch block.
HTH,
Paul

[jklb]

Ugh ... at some point my thinking got confused and I associated uncaught exceptions with Unix signals that can't be caught or trapped. I've seen Java code examples where that certainly wasn't the case, but my thinking became muddled anyway.

That's what so good about these mock tests ... sometimes they're like head slaps!

[bptoth]

Given the current form of the example code it seems that technically the correct answer is "The program will not compile", because i is an unitialized automatic variable; and readers might consider this one of those trick questions that is likely oriented to a certain topic (assertions in this case) but in fact it is about whether they notice some hidden trap in the code

To avoid possible confusion stemming from this, I would suggest to clearly emphasize in some way, that the variable is definitely going to be initialized; e.g. make it a class field or add a more telling comment/explanation

[admin]

The given code already contains a line right below int i; that says //code that initializes i goes here. So it is quite clear that i is being initialized.

[fariz.siracli]

Because it can be caught by a try/catch block.
HTH,
Paul

But explanation says :
However, in this case, the catch block is catching an Exception so it will not catch an AssertionError. Thus, this method will throw an AssertionError if 'i' is not equal to 20 and the System.out.println(i) will not be executed. Note that AssertionError extends Error and is not a subclass of Exception, so cannot be caught by a catch block catching Exception.

[admin]

Yes, that is correct. I am not sure I understand your question. AssertionError can be caught using a try/catch block but not with the one that is given in the question. To catch AssertionError, you need a catch(AssertionError ae) or a catch with its super class. The one given in the question is catching an Exception (with capital E), it cannot catch AssertionError.
Paul.

[fariz.siracli]

I think i understood. Thank you.
I thought that "caught using a try/catch block." is meant to be the try/catch block which is in code .Now i understood that it means generally.

[dieterdde]

Weird, I selected "won't compile" for the reason that there is no code in the try-block which might throw an Exception. So i thought it wouldn't compile with reason "Code unreachable" because that catch block can never be reached (which I wrongly assumed).

I knew indeed that you cannot catch an AssertionError with Exception, hence my rationale that the catch block can't be reached.

But I just tried it and indeed, it compiles fine. Why is that? I could have sworn i've had cases in the past getting unreachable code or something to the extent that no such exception is being thrown in the try block.

Like this: Unreachable catch block for FileNotFoundException. This exception is never thrown from the try statement body.

Why does it not compile with catch FileNotFoundException but it does compile with catch Exception?

Is Exception the only checked exception that doesn't exhibit this unreachable code behaviour?

Could it be because RuntimeException inherits from Exception, and since RuntimeExceptions are OK, it means anything above (e.g. Exception & Throwable) are also OK? Just tested, and sure enough, catch Throwable also doesn't complain.

Cheers,
Dieter

[admin]

FNE is a checked exception. If any code threw this exception then it would have to be declared. Thus, for any code snippet the compiler can easily know whether there is a possibility of a FNE to be thrown. If there is no such possibility, and if you still try to catch it, the compiler knows that this is unreachable.

Exception is also checked exception but one of its subclasses is RuntimeException, which is unchecked. Since any code can throw a RTE without any declaration, the compiler can never be sure whether this exception can possibly be thrown or not by any given block of code and so it allows a catch block for RTE and any of its super classes.

[dieterdde]

FNE is a checked exception. If any code threw this exception then it would have to be declared. Thus, for any code snippet the compiler can easily know whether there is a possibility of a FNE to be thrown. If there is no such possibility, and if you still try to catch it, the compiler knows that this is unreachable.

Exception is also checked exception but one of its subclasses is RuntimeException, which is unchecked. Since any code can throw a RTE without any declaration, the compiler can never be sure whether this exception can possibly be thrown or not by any given block of code and so it allows a catch block for RTE and any of its super classes.

Yep, great, learned something new again! This is the best way of learning, to take mock exams, and be surprised about some of the answers, you'll never forget those!

Cheers
Dieter