这个问题其实无须过多困扰。也没有必要往JDK1.7的try-with-resources上扯。
首先关闭资源放在try块里一定会有问题：资源可能不被关闭。
所以资源的关闭应该放在finally里，这没有什么疑问。
至于finally块里close资源会额外引入IOE,这也是无法避免的。IOE,这也是无法避免的。
目前(就我见到过的)绝大多数代码里，捕获IOE目前(就我见到过的)绝大多数代码里，捕获IOE后，最多打一条log，更多的是noop，即no operations，do nothing。
close的时候IOE发生的几率很小，它应该属于一种操作系统层面的error，选择忽略它是正确的选择，毕竟你的系统不能因为一个资源关闭错误而停止运行。况且，如果你硬要捕获这个IOE，那能做些什么呢。

如果不想在finally块里引入try-catch，我见过guava的一种关闭方式，写个工具方法叫做closeQuietly()，不吵不闹就挺好。

谢邀
可以考虑Java7的try with resource

try (BufferedReader br = ...) {
    //...
} catch (IOException ex) {
    //...
}

参考

来一发安利，Lombok，一个可以让你少些很多代码的增强库。

@CleanUp

同意1楼的答案，你补充的问题，也是由于IDE的问题。

另外对于实现了 AutoCloseable 和 Closeable 接口的资源，最好都使用 try-with-resources结构。

以你的代码作为例子,省略了一些代码

try{
    reader.readline();
}catch(IOException e){
    e.printStackTrace();
}finally {
    try {
       reader.close();
    } catch (IOException e) {
       e.printStackTrace();
    }
}

假设 readline 和 close 都发生io异常,使用 JDK1.7 前的异常捕捉结构，只能捕捉到 close 的异常，readline 的异常被抑制了。（因为 finally 的代码必须执行）

另外一个问题，在 try-with-resources 中资源的 AutoCloseable 的 close 方法什么时候执行？

在执行完 try 代码块的代码之后就会执行（这里不贴实验代码了）,所以使用 try-with-resources 的结构，catch 块和 finally 块都是在资源进行关闭之后才会执行的。