This restriction is not applicable to constructors. That is why the constructor in the above code is fine.
In the context of a checked exception, I understand. However and assuming that I copied and pasted correctly, could you please comment on why the compiler would concern itself with an unchecked exception (being thrown) in the instance initializer and also the constructor? Secondly, my results are different, have I copied and pasted this incorrectly? Third, will Enthuware possibly prepare a Java SE 11 Programmer II | 1Z0-816 (or equivalent) book?
1. The difference that it is talking about is in the compilation step. Compiler does not accept the throws statement in instance initializer but accepts the same in the constructor. The comment "//this line is fine" in the constructor is about that as it relates to the point being discussed in that paragraph. At run time, of course, the exception will be thrown as you have observed.
2. Regarding why this difference exists. I am afraid, the reason is not discussed in JLS but if I were to guess, it relates to eliminating scope for bugs. If the compiler can determine that the instance creation of the class can never succeed, it is probably a bug or is not something that the programmer desired. It does this analysis for instance initializers but not for constructors.
3. We do not have any information about that as of now. Do you think this one (for 808) is helpful? Please do give us your feedback.
If you like our products and services, please help us by posting your review here.
Like those answers, I've found the book to be very extremely well done. I really enjoy the no surgical shortcuts, and thinking of code as physical replaceable components approach. I think this approach speaks volumes in helping to solidify my knowledge required long term, and to it's purpose, for the 808 exam. There have been many many concepts that I've found were very well explained (even after having read other books over the years), one or two of which I personally have commented on, within this forum, on how very helpful they were. Secondly, I've found the Time API coverage to be second to none (well at least, compared to the other 2 808 books that I've read [and I know that this information may not be as important for 816]).