The variable in a multi-catch expression is effectively final.
Should be implicitly final.
An exception parameter of a multi-catch clause is implicitly declared final, so will never occur as the left-hand operand of an assignment operator, but it is not considered effectively final.
I just noticed that the examples in the Rethrowing Exceptions section of Chapter 6 (starting on page 305) treat DateTimeParseException as if it's a checked exception.
But DateTimeParseException extends DateTimeException, which extends RuntimeException.
On page 305:
Suppose that we have a method that declares two checked exceptions:
On page 306:
(...) we need to handle or declare those two exception types.
and so on.
Perhaps DateTimeParseException could be swapped for ParseException in the examples?
page 302 - agreed and logged
page 314 and 561 - interesting. I wasn’t aware of that distinction. It makes sense though. It’s a hacky type of final . Cow for teaching me something!
The DateTimeException was noticed here. You noticed it first, but I logged it first from that thread.
Thanks for checking these. And thanks for the cow! To be honest, I didn't even know what effectively final was before I read your book. It's all an ongoing learning process
OCA Java 6, OCP Java 6, OCP Java 8
girl power ... turns out to be about a hundred watts. But they seriuosly don't like being connected to the grid. Tiny ad: