try..catch VS long if() [英] try..catch VS long if()

查看:127
本文介绍了try..catch VS long if()的处理方法,对大家解决问题具有一定的参考价值,需要的朋友们下面随着小编来一起学习吧!

问题描述

我的项目中有一个复杂的模型结构。

有时我必须从中获取的值。它看起来如下:

I have a complex model structure in my project.
Sometimes I have to get a deep placed value from it. It looks like following:

something.getSomethongElse().getSecondSomething().getThirdSomething().getFourthSomething();

问题是每个方法都可以返回 null ,如果有的话,我会得到 NullPointerException

The problem is that each of those methods could return null, and I will get NullPointerException in case if it does.

我想知道的是我应该写多长时间,如果

What I want to know is should I write long if like

if(something != null && something.getSomethongElse() != null && something..getSomethongElse().getSecondSomething() != null && something.getSomethongElse().getSecondSomething().getThirdSomething() != null && omething.getSomethongElse().getSecondSomething().getThirdSomething().getFourthSomething() != null) {
    //process getFourthSomething result.
}

或者只是使用try..catch如下:

Or it is OK just to use try..catch like following:

SomethingFourth fourth = null;

try {
    fourth = something.getSomethongElse().getSecondSomething().getThirdSomething().getFourthSomething();
} catch (NullPointerException e) { }

if(fourth != null) {
    ///work with fourth
}

我知道 NPE 是要避免的事情,但不是在我的情况下避免它的开销是什么?

I know that NPE is a thing to be avoided, but isn't it overhead to avoid it in my case?

推荐答案

如果你可以重构代码并使每个方法返回可选。可以避免空检查并尝试... catch。

If you can refactor the code and make each method return Optional. It will be possible to avoid null checks and try ... catch.

Optional<Result> result = something.getSomethingElse()
.flatMap(e -> e.getSecondSomething())
.flatMap(x -> x.getThirdSomething())
.flatMap(e -> e.getFourthSomething());
// at the end to check if result is present
result.ifPresent(..some_logic_here..); // or result.orElse(...);

所以 getSomethingElse()返回可选< SomethingElse> getThirdSomething() - 可选< ThirdSomething> 和等等。我们必须在这里使用 flatMap(函数<?super T,可选< U>> mapper),因为如果提供的映射器是一个结果已经是可选的映射器,并且如果在调用时,flatMap不会使用附加的Optional包装它。换句话说,如果在地图(e - > e.getSecondSomething()) map ,结果类型将为可选<可选< SecondSomething>> 我们将不得不执行不必要的 get()调用 - 地图(...)。得到()。地图(...)

so getSomethingElse() returns Optional<SomethingElse>, getThirdSomething() - Optional<ThirdSomething> and so on. We have to use here flatMap(Function<? super T,Optional<U>> mapper) because if the provided mapper is one whose result is already an Optional, and if invoked, flatMap does not wrap it with an additional Optional. In other words if map on map(e -> e.getSecondSomething()) the result type will be Optional<Optional<SecondSomething>> and we will have to do unnecessary get() call - map(...).get().map(...).

我希望这会有所帮助。

更新
你可以使用方法引用做同样的事情。

UPDATED You can do the same thing using method references.

Optional<Result> result = something.getSomethongElse()
            .flatMap(SomethongElse::getSecondSomething)
            .flatMap(SecondSomething::getThirdSomething)
            .flatMap(ThirdSomething::getFourthSomething);

这篇关于try..catch VS long if()的文章就介绍到这了,希望我们推荐的答案对大家有所帮助,也希望大家多多支持IT屋!

查看全文
登录 关闭
扫码关注1秒登录
发送“验证码”获取 | 15天全站免登陆