我今天高高兴兴,想写个简单的统计一个项目下有多少行代码的小程序,于是咔咔的写下:
long count = Files.walk(Paths.get("D:/Test")) // 获得项目目录下的所有目录及文件 .filter(file -> !Files.isDirectory(file)) // 筛选出文件 .filter(file -> file.toString().endsWith(".java")) // 筛选出 java 文件 .flatMap(file -> Files.lines(file)) // 按行获得文件中的文本 .filter(line -> !line.trim().isEmpty()) // 过滤掉空行 .count(); System.out.println("代码行数:" + count); 复制代码
题外话: Files.walk(Path)
在 JDK1.8 时添加,深度优先遍历一个 Path
(目录),返回这个目录下所有的 Path
(目录和文件),通过 Stream<Path>
返回; Files.lines(Path)
也是在 JDK1.8 时添加,功能是返回指定 Path
(文件)中所有的行,通过 Stream<String>
返回
然后,编译不过 —— 因为 Files.lines(Path)
会抛出 IOException
,如果要编译通过,得这样写:
long count = Files.walk(Paths.get("D:/Test")) // 获得项目目录下的所有文件 .filter(file -> !Files.isDirectory(file)) // 筛选出文件 .filter(file -> file.toString().endsWith(".java")) // 筛选出 java 文件 .flatMap(file -> { try { return Files.lines(file); } catch (IOException ex) { ex.printStackTrace(System.err); return Stream.empty(); // 抛出异常时返回一个空的 Stream } }) // 按行获得文件中的文本 .filter(line -> !line.trim().isEmpty()) // 过滤掉空行 .count(); System.out.println("代码行数:" + count); 复制代码
我的天,这个时候我强迫症就犯了——因为这样的 Lambda
不是 one-liner expression
,不够简洁,也不直观。如果 Stream
的流式操作中多几个需要抛出受检异常的情况,那代码真是太难看了,所以为了 one-liner expression
的 Lambda
,我们需要解决的办法。
通过新建一个方法( :) 无奈但是纯洁的微笑)
public static void main(String[] args) throws Exception { long count = Files.walk(Paths.get("D:/Test")) // 获得项目目录下的所有文件 .filter(file -> !Files.isDirectory(file)) // 筛选出文件 .filter(file -> file.toString().endsWith(".java")) // 筛选出 java 文件 .flatMap(file -> getLines(file)) // 按行获得文件中的文本 .filter(line -> !line.trim().isEmpty()) // 过滤掉空行 .count(); System.out.println("代码行数:" + count); } private static Stream<String> getLines(Path file) { try { return Files.lines(file); } catch (IOException ex) { ex.printStackTrace(System.err); return Stream.empty(); } } 复制代码
这种解决方法下,我们需要处理受检异常 —— 即在程序抛出异常的时候,我们需要告诉程序怎么去做(getLines 方法中抛出异常时我们输出了异常,并返回一个空的 Stream)
将会抛出异常的函数进行包装,使其不抛出受检异常
如果一个 FunctionInterface 的方法会抛出受检异常(比如 Exception),那么该 FunctionInterface 便可以作为会抛出受检异常的 Lambda 的目标类型。
我们定义如下一个受检的 FunctionInterface
:
@FunctionalInterface interface CheckedFunction<T, R> { R apply(T t) throws Throwable; } 复制代码
那么该 FunctionalInterface
便可以作为类似于 file -> File.lines(file)
这类会抛出受检异常的 Lambda
的目标类型,此时 Lambda
中并不需要捕获异常(因为目标类型的 apply
方法已经将异常抛出了)—— 之所以原来的 Lambda
需要捕获异常,就是因为在流式操作 flatMap
中使用的 java.util.function
包下的 Function<T, R>
没有抛出异常:
java.util.function.Function 复制代码
那我们如何使用 CheckedFunction
到流式操作的 Lambda
中呢?
首先我们定义一个 Attempt
接口,它的 apply
静态方法提供将 CheckedFunction
包装为 Function
的功能:
public interface Attempt { static <T, R> Function<T, R> apply(CheckedFunction<T, R> function) { Objects.requireNonNull(function); return t -> { try { return function.apply(t); } catch (Exception ex) { throw new RuntimeException(ex); } }; } } 复制代码
然后在原先的代码中,我们使用 Attempt.apply
方法来对会抛出受检异常的 Lambda
进行包装:
long count = Files.walk(Paths.get("D:/Test")) // 获得项目目录下的所有文件 .filter(file -> !Files.isDirectory(file)) // 筛选出文件 .filter(file -> file.toString().endsWith(".java")) // 筛选出 java 文件 .flatMap(Attempt.apply(file -> Files.lines(file))) // 将 会抛出受检异常的 Lambda 包装为 抛出非受检异常的 Lambda .filter(line -> !line.trim().isEmpty()) // 过滤掉空行 .count(); System.out.println("代码行数:" + count); 复制代码
此时,我们便可以选择是否去捕获异常 (RuntimeException)
。这种解决方法下,我们一般不关心抛出异常的情况 —— 比如自己写的小例子,抛出了异常程序就该终止;或者你知道这个 Lambda 确实 100% 不会抛出异常。
不过我更倾向于抛出异常时,我们来指定处理的方式:
static <T, R> Function<T, R> apply(CheckedFunction<T, R> function, Function<Throwable, R> handler) { Objects.requireNonNull(function); Objects.requireNonNull(handler); return t -> { try { return function.apply(t); } catch (Throwable e) { return handler.apply(e); } }; } 复制代码
比如我们前面的例子,如果 file -> Files.lines(file)
抛出异常了,说明在访问 file
类的时候出了问题,我们可以就假设这个文件的行数为 0
,那么默认值就是个空的 Stream<String>
(当然你也可以选择顺手记录一下异常):
long count = Files.walk(Paths.get("D:/Test")) // 获得项目目录下的所有文件 .filter(file -> !Files.isDirectory(file)) // 筛选出文件 .filter(file -> file.toString().endsWith(".java")) // 筛选出 java 文件 .flatMap(TryTo.apply(file -> Files.lines(file), ex -> Stream.empty())) .filter(line -> !line.trim().isEmpty()) // 过滤掉空行 .count(); System.out.println("代码行数:" + count); 复制代码
使用 CheckedFunction
这种方式更为通用 —— 类似的,我们可以包装 CheckedConsumer
为 java.util.function.Consumer
,包装 CheckedSupplier
为 java.util.function.Suppiler
, CheckedBiFunction
为 java.util.function.BiFunction
等:
public interface Attempt { ...... /** * 包装受检的 Consumer */ static <T> Consumer<T> accept(CheckedConsumer<T> consumer) { Objects.requireNonNull(consumer); return t -> { try { consumer.accept(t); } catch (Throwable e) { throw new RuntimeException(e); } }; } /** * 包装受检的 Consumer,并自定义异常处理 */ static <T> Consumer<T> accept(CheckedConsumer<T> consumer, Consumer<Throwable> handler) { Objects.requireNonNull(consumer); Objects.requireNonNull(handler); return t -> { try { consumer.accept(t); } catch (Throwable e) { handler.accept(e); } }; } } 复制代码
本文 Attempt 接口的代码:公众号回复:20191015Attempt
就我个人观点而言,我真的不喜欢 Java 中的受检(Checked)异常,我认为所有的异常都应该是非受检(Unchecked)的 —— 因为一段代码如果会产生异常,我们自然会去解决这个问题直到其不抛出异常或者捕获这个异常并做对应处理 —— 强制性的要求编码人员捕获异常,带来的更多的是编码上的不方便和代码可读性的降低(因为冗余)。不过既然受检异常已经是 Java 中的客观存在的事物,所谓“道高一尺,魔高一丈” —— 总是会有办法来应对。