Stream API和lambda是Java自版本8以来很大的一个特性。从那个时候开始，我们可以更多地使用函数式的语法。现在，在使用了这些语言特性一段时间之后，我们经常面临的一个问题是如何在lambda里处理checkedException。
你很可能已经知道，直接在lambda里调用抛出checkedException的方法是不行的,我们需要catch住checkedException才能让代码通过编译。简单来说，我们可以直接在lambda里try-catch住异常并封装成一个RuntimeException，也就是下面第一个例子。但是我想我们能够认同的一点是这个方法不是最优雅的。
myList.stream()
.map(item -> {
try {
return doSomething(item);
} catch (MyException e) {
throw new RuntimeException(e);
}
})
.forEach(System.out::println);
但是，Lambda里包含一大块代码会显得很笨拙，并且可读性会降低，这个观点大部分人都明白。我个人认为，这种情况应该尽量避免。如果在lambda里我们需要的代码不止一行，最好的方式是把lambda的内容抽取出来封装成一个单独的方法，然后再直接调用这个方法。对于lambda里的checkedException，一个更好的且可读性强的方式是把lambda调用的原函数使用try-catch封装一下，然后再去调用它。
myList.stream()
.map(this::trySomething)
.forEach(System.out::println);
private Item trySomething(Item item) {
try {
return doSomething(item);
} catch (MyException e) {
throw new RuntimeException(e);
}
}
这种方式至少提高了可读性，并且将异常处理分离出来了。如果想要是catch住异常然后进行处理，而不只是简单地包装成RuntimeException的话，这是个勉强可行并且可读的方案。
RuntimeException
很多场景下，你会发现大家都会用这种方式去重新把异常包装成一个RuntimeException或者一个更具体的uncheckedException。这样一来，被包装的方法就可以被lambda或者更高阶的函数调用了。
我也比较熟悉这种处理方式，但是个人感觉checked exception没有什么实际的存在意义，但是我不想在这里争论这点。如果你想把lambda里调用的每个抛出checkedException的方法包装成跑出RuntimeException，你会发现你一直在重复上面这种模式。为了避免写重复代码，为什么不把它封装成一个工具函数呢？这样的话，你只需要写一次就可以到处使用了。
要这样做的话，首先你要定义一个函数接口(functional interface)来表示你的函数。只有在这时候，你才需要声明异常。
@FunctionalInterface
public interface CheckedFunction\<T,R\>
R apply(T t) throws Exception;
}
现在，你可以写一个通用的工具函数来包装你刚刚在函数里定义的CheckedFunction。你可以在这个工具函数里用try-catch处理异常，然后把原始的异常转换成一个RuntimeException（或者其他的uncheckedException）。我知道我们现在又有了一个另外的一个丑陋的lambda表达式，而且你可以继续将这个抽取成一个函数。但是至于要不要为这个单独的lambda进行抽取封装，取决于你自己。
public static <T,R> Function<T,R> wrap(CheckedFunction<T,R> checkedFunction) {
return t -> {
try {
return checkedFunction.apply(t);
} catch (Exception e) {
throw new RuntimeException(e);
}
};
}
现在，只要一个简单的static import，你就可以用这个新的工具函数来包装lambda里会抛出异常的函数。从这个地方开始，一切就变得比较顺畅了。
myList.stream()
.map(wrap(item -> doSomething(item)))
.forEach(System.outprintln);
仔细想想，这个地方还有一个问题，就是在出现异常的时候，stream流的处理会立即终止。如果这个对你没影响的话， 那就无所谓了。但是我可以清楚的一点就是，直接终止处理对于很多场景不是最佳解决方案。
Either
在使用stream的时候，我们可能不想被异常终止。如果你的stream里包含大量的要处理的数据，你期望在譬如说第二条出错的时候终止整个流程吗？很可能不是。
让我们换一个角度来思考。为什么不把“异常场景”当做很有可能会出现的一种“正常场景”来进行处理呢。然后我们再来把这两种场景都看作是数据，连续地进行处理，最后再来决定结果。这种操作是可以实现的，但是要实现它，我们需要引入一个新的类型 — Either。
Either是函数式语言里很常见的一种类型，但是Java里（目前）还没有。和Optional类型相似，Either是对两种结果的一种包装。它可以是左值的（Left）或者是右值的（Right），也可以都不是。左值和右值都可以是任意类型的。举个例子，如果我们有个Either类型，它的值可以是一个String或者Integer， Either<String,Integer>
如果我们用这个方式来进行异常处理，我们可以用一个可以是Exception或者任意值的Either。为了方便起见，一般左值是Exception右值是正常处理的数据。你可以这样来记忆，right不仅仅是左手边，它也表示”good”, “ok”。（译者注：英文里right有右边，也有正确的意思）
下面的代码展示了Either类型的一个基本实现。在这里，我用了Optional类型来包装左右节点返回的值。
public class Either<L, R> {
private final L left;
private final R right;
private Either(L left, R right) {
this.left = left;
this.right = right;
}
public static <L,R> Either<L,R> Left( L value) {
return new Either(value, null);
}
public static <L,R> Either<L,R> Right( R value) {
return new Either(null, value);
}
public Optional<L> getLeft() {
return Optional.ofNullable(left);
}
public Optional<R> getRight() {
return Optional.ofNullable(right);
}
public boolean isLeft() {
return left != null;
}
public boolean isRight() {
return right != null;
}
public <T> Optional<T> mapLeft(Function<? super L, T> mapper) {
if (isLeft()) {
return Optional.of(mapper.apply(left));
}
return Optional.empty();
}
public <T> Optional<T> mapRight(Function<? super R, T> mapper) {
if (isRight()) {
return Optional.of(mapper.apply(right));
}
return Optional.empty();
}
public String toString() {
if (isLeft()) {
return "Left(" + left +")";
}
return "Right(" + right +")";
}
}
现在，你可以让你自己的函数返回Either而不是抛出异常了。但是对于你想在lambda里使用抛出checkedException函数的场景，这个还是不行。因为，我们需要在Either类型里添加一个小的工具函数。
public static <T,R> Function<T, Either> lift(CheckedFunction<T,R> function) {
return t -> {
try {
return Either.Right(function.apply(t));
} catch (Exception ex) {
return Either.Left(ex);
}
};
}
通过在Either里添加这个静态的lift方法，我们现在可以简单地“改进”一个抛出checkedException的函数，让它返回一个Either对象。如果我们现在回到最原始的问题上，我们现在拿到的是一个Either的流（Stream），而不是一个包含RuntimeException的不稳定的流（Stream）。
myList.stream()
.map(Either.lift(item -> doSomething(item)))
.forEach(System.out::println);::
这样一来，我们就能够很好地控制后面的处理逻辑了。通过使用Stream API，我们可以很容易地过滤出左值，比如说，去用来输出日志。你也可以只过滤出右值，然后忽略出现异常的场景。不管怎么做，现在你都能够很好控制处理逻辑了，并且你的Stream流不会因为RuntimeException而被立即终止。
因为Either是一个通用的包装（wrapper），它可以用于任何类型，不仅限于异常处理。也就是说，我们可以不仅仅只是把异常封装到Either的左值里。目前这种方式存在的一个问题是，如果出现异常我们没法重试，因为我们没有保存原始参数。因为Either可以保存任何类型，所以我们可以在它的左值里保存异常信息和原始值。要达到这样的效果，我们可以添加第二个静态的lift函数。
public static <T,R> Function<T, Either> liftWithValue(CheckedFunction<T,R> function) {
return t -> {
try {
return Either.Right(function.apply(t));
} catch (Exception ex) {
return Either.Left(Pair.of(ex,t));
}
现在可以看到，在这个liftWithValue函数里，返回了一个Pair类型，里面包含了异常信息和原始值。现在，一旦出现异常，我们有了所有必须的信息，而不只是一个Exception。
Pair类型也是一个很通用的类型，你可以在Apache Commons包里找到它，或者你也可以自己去实现一个。无论怎么说，它只是一个能保存两个值的简单类型。
public class Pair<F,S> {
public final F fst;
public final S snd;
private Pair(F fst, S snd) {
this.fst = fst;
this.snd = snd;
}
public static <F,S> Pair<F,S> of(F fst, S snd) {
return new Pair<>(fst,snd);
}
}
通过liftWithValue函数，我们现在可以完美地控制在lambda里抛出异常的函数。当Either是右值的时候，我们就可以知道函数正常地执行了，我们可以获得执行结果。如果Either是左值的时候，我们就会知道函数调用出现了异常，我们可以取得出现的异常以及导致异常的参数，然后可以按需进行处理。通过使用Either，而不是将checkedException包装成RuntimeException，我们可以避免Stream流被意外终止。
Try
有些使用Scala语言的人可能会使用Try类型而不是Either来进行异常处理。Try类型和Either很相似。它，同样的，有两种场景：“成功”或者“失败”。失败的场景只能保存Exception，不过成功的场景可以保存任何值。所以，Try只是Either类型的一种特殊实现，并且它的左值（失败的场景）的类型固定的是Exception。
public class Try<Exception, R> {
private final Exception failure;
private final R succes;
public Try(Exception failure, R succes) {
this.failure = failure;
this.succes = succes;
}
}
有些人认为这个更好用，但是我认为因为Try在失败的场景下只能保存异常信息，那么它就会存在我们上面提到的无法重试的问题。我个人更喜欢Either类型。不过，无论你是使用Either或者Try，你都已经解决了前面提到的异常处理的问题，你不会因为RuntimeException导致Stream流异常终止。
类库
Either和Try类型本身实现都很简单。但是，另一方面，你也可以参考一下现成的类库。例如，VAVR（以前叫Javaslang）就由对这两种类型以及相应工具函数的实现。我强烈建议你仔细看看这个库，因为它还有很多其他类型。无论怎样，在使用的时候，你还是要好好考虑一下，对于仅仅这个异常处理的场景，你是需要加入一个大的类库依赖还是自己写几行简单代码来实现。
结论
当你在使用一个抛出checkedException的函数式，如果你想要在lambda里使用它，你需要做一些额外的工作。将异常包装成RuntimeException是一种可行的方案。如果你喜欢这种方式，我强烈建议你创建一个简单的工具包装函数，然后重复利用它，这样的话，你就不用每次都使用try/catch了。
如果你想更细致地进行控制的话，你可以使用Either或者Try类型来包装函数的输出，这样你就可以把执行结果直接当做数据来进行处理。Stream流也不会因为RuntimeException而被终止，并且你可以自由地在stream里对它进行处理。
