Anyway, since the “exception swallowing” came up a few times I added the discussion in the comments to the post itself as an update.

Thanks!

However, I changed this for a certain reason. First, since it uses the PhantomReference trick, it means that within normal operations such as creating a new AutoclosePool, use()ing a resource or close()ing a pool it would clean previously unclosed pools. This allows for the pool to be safely discarded if forgotten.
However, it also meant that close() doesn’t guarantee that the exceptions thrown are your exceptions and not some other pool’s exceptions. This could be mended of course, but because of the rest of the behavior, I thought it would be easier to just hide the exceptions altogether.

To solve this, I did add an optional ExceptionHandler which receives the exceptions when they occur; this way, whenever an exception does occur it would be notifying the application in the correct context (a handler’s context).

Do you think a different design is preferred?

void copy(String source, String target) throws IOException {
InputStream is = new FileInputStream(source);
try {
OutputStream os = new FileOutputStream(target);
try {
// do the copying
} finally {
os.close();
}
} finally {
is.close();
}
}

Note the use of the nested finally blocks; this guarantees that everything always gets closed, without null checks. (It is even a bit safer, in case fis.close() threw some RuntimeException.) The downside is deeper indentation, I guess.

Note also that opening streams and working with them can usually throw IOException, so there is no need to catch it when closing. Better to have the exception be thrown and properly reported than ignored (meaning something might be very wrong and you don’t know it). IMHO AutoclosePool.close() should be declared to throw IOException; it could collect any IOException’s coming from the pool’s members and either arbitrarily pick one to rethrow at the end, or (if you cared a lot about diagnostics) stack them together using Throwable.initCause.