nick woodward wrote:However I got the answer wrong, on the basis that try blocks must be able to throw the type of Exception specified in the catch block (so I thought the compiler would complain).
I assume I'm wrong because Exception could be RuntimeException? Replacing the catch block with a more specific checked exception gives the answer I would've expected.
nick woodward wrote:oh, and as an aside - question 15 has me worried about the semantics of the questions (it references an IOException without import or qualification as an answer). Are there any particular nuances that occur with the question wording ('given', 'code snippet', 'code fragment' etc) that I should be wary of? I don't know why, but that question really rubbed me up the wrong way!
nick woodward wrote:*edit... does it not compile? hang on, give me a sec, it looks like it does
nick woodward wrote:I'm so tempted to try and compile it.....(i won't) it must be new Gotcha.go();
nick woodward wrote:And the compiler is too stupid to see the stackoverflow problem.
...
**yup. i'm an idiot! new Gotcha().go();
nick woodward wrote:what i was unclear about was the rule that the try block has to be able to throw the exception described in the catch clause. In the case where catch has 'Exception' as the argument, this rule doesn't apply, because any code can throw an unchecked exception, therefore the try block always has the ability to throw a subclass of Exception. (whereas with something like java.io.IOException you'd have to have an explicit throw or call to a method that declares that exception to be thrown)
Correct?
Roel De Nijs wrote:
nick woodward wrote:*edit... does it not compile? hang on, give me a sec, it looks like it does
Of course! Otherwise I would not mention itYou should know by now that I am the personification of a Java compiler
![]()
Roel wrote:
"If I'm too stupid, why does he need/use me to spot such an obvious compiler error"
nick woodward wrote:Roelpiler? comproeler?
nick woodward wrote:abc() fails because it isn't possible to throw an IOException in the try block (although I'm tempted to say it's ok because the declared exception in abc() is the superclass of IOE - but i'm pretty sure that's wrong, IOException is still pointless)
nick woodward wrote:klm() fails for the same reason. klm throws no checked exceptions, so IOException is the problem. the catch clause with Exception is fine because klm() could throw a runtime exception.
nick woodward wrote:sounds like you rule the compiler
nick woodward wrote:so the declaration in abc() isn't saying it *will* throw Exception, it's saying it'll throw anything up to Exception.
Roel De Nijs wrote:
nick woodward wrote:so the declaration in abc() isn't saying it *will* throw Exception, it's saying it'll throw anything up to Exception.
Indeed! A throws clause indicates the method could throw that exception or any of its subclasses.
But why does the tuv() method compiles successfully?
nick woodward wrote:because the Exception catch clause mops up anything thrown that isn't an IOException (because abc() can throw exceptions that are broader than IOE), and IOE is allowed because it's a subclass of Exception and therefore contains the code to deal with a specific type of Exception that abc() could throw. Namely IOE or FNFE
nick woodward wrote:z1:
nick woodward wrote:z2:
nick woodward wrote:z3:
Roel De Nijs wrote:
Roel De Nijs wrote:
Roel De Nijs wrote:
you are allowed to have a catch handler for a broader exception.
nick woodward wrote:NPE is caught, along with all other runtime exceptions, by the Exception block.
FNFE is dealt with by the superclass IOException
CustomException causes a compiler error.
nick woodward wrote:if memory serves, i got this one wrong. and i'd still get it wrong today.
Exception block deals with runtime exceptions potentially thrown
FNFE block deals with the related exception thrown by z0
IOException is unnecessary - I would still say this *should* cause an error (but I'll look at your explanation after this post)
nick woodward wrote:the order of catch blocks is wrong for the runtime exceptions. also the Exception catch block is now pointless, because the runtime exceptions it was catching are now dealt with earlier in the RTE block.
nick woodward wrote:i guess if that only causes a warning by the compiler, i can remember that.
nick woodward wrote:so basically, if the a catch block is "unreachable", because it's preceded by a subclass block, and only that subclass is thrown, you get a warning. if the exception, or its subclasses are never thrown, it won't compile.
nick woodward wrote:so in z0 - if we ignore the runtime exception order (or fix it), the compiler should warn us about the Exception block (and the Runtime block, if the order was corrected.). am going to go try this out!
You got style baby! More than this tiny ad:
Smokeless wood heat with a rocket mass heater
https://woodheat.net
|