Marcelo Canaparro wrote:how come it is able to close both resources in spite of the first that is closed throwing an exception
The short answer: Because it's designed to work that way. A language feature which guarantees automatic closing of resources wouldn't be very useful if throwing an exception could prevent a resource from being closed automatically.
The longer answer: well, have a look at for example this tutorial, especially the part headed "Try-with-resources Exception Handling".
then after that code, code, code terminates, you're guaranteed that the resource will be closed. That's pretty much it. Whether execution fell through after the end, or an exception was thrown, or you returned from the enclosing method, or you called break or continue to go to the next execution of the enclosing loop, doesn't matter, the resource will be closed.
The only situations that one might consider to be exceptions to that rule are when the code, code, code terminates abruptly. That means that it called System.exit or equivalent, or that something outside the program caused it to end. Someone killed the process, the power went off, that sort of thing.
A lot of Java's rules are simpler than you would think if you just take them to mean what they say. For example you might ask "Well, what if the code inside the try block goes into an infinite loop?" But in that case the code doesn't terminate and the rule "When the code terminates..." doesn't apply, so the resource isn't automatically closed. That's why the short answer really tells you all you need to know.
That made me think, “Can you get code to go into an infinite loop inside try with resources?”The idea of line 5 is to omit anything not an int, but I have written a semicolon (isn't it nice to write crappy code when it can't do any harm) and accidentally on purpose forgotten to get rid of the next token by calling scanner.next() or similar. The Scanner will spend the rest of eternity the session's lifetime looking at the same token and lo and behold, an infinite loop