看完这块代码,我久久不能平静

为啥

@TmacV2 url 为空的时候直接调用就会抛出 NullPointerException

真没想到能遇上这样的代码,以前看着别人的截图也就乐乐

这个 catch 是为可能是不合法的或者无法访问的 url 准备的

可能是为了方便在 catch 中处理空指针异常

遇到 NullPointerException，严禁使用 catch 来隐藏编码错误

@w4w #6
catch 的是 IOException

@xuanbg 这个 catch 应该是管网络 IO 不可用的异常

看完这个帖子，我久久不能平静

@ignore 能把完整代码贴出来么？显式抛 NPE 很可能是为了快速失败（ fail-fast ）
https://stackoverflow.com/questions/45632920/why-should-one-use-objects-requirenonnull/45632988

可能完全是为了终止当前语句块，但是又不想终止方法，可以用下面的骚操作实现：
do {
if (url == null) {
break;
}

} while (false)

距离发帖过去 1 小时 20 分钟了，现在心情平静了吗？

现在平静了吗

现在平静了吗
楼主你这么容易激动，对不起你这个 ID 啊。:doge

背后的原因让人暖心

@pkupyx 对的，url 不为空不代表 url 就正确返回结果，请求出现异常是最正常不过的事情。这时候抛出异常显然不合适，所以要用 try/catch 吃下来 IOException，并通过日志输出异常。

@LGA1150 #7 赞同这位老哥，这个他手动抛空指针了，后面代码不一定会抛... 所以看情况。这代码确实不太好。11 楼那个看起来更舒服点

我觉得这个代码很好啊（前提是出 null 真是异常而不是预期中的错误）。谁知道我一个 null 放后面的库都会干些啥，到时候真有 null 了都不知道怎么调试。

唯一槽点，扔到了 try 里面。没啥大问题。

感觉没啥毛病啊。。入不合法还不让抛异常了吗

没毛病，很可能是等后面自动抛 npe 就晚了，抛异常前已经执行的语句又不能回滚的，

还不平静吗？

保护代码在正常条件下执行而已，难道你从来不检查参数的吗

我觉得很多时候这是正确的编码方式，Java 里毕竟没有 checkNotNull

这个就是 guava 的 precondition.checknotnull 吧

不是十分的优雅，不过没觉得有太大的问题。

不晓得♂ 也许是为了把这种业务错误在这个代码块捕捉完也说不定

@guyeu 抛 npe 就很奇怪了吧？

@mengkun #23 emmmm

throw NullPointerException，catch IOException

@iseki #25
Objects.requireNonNull

@LGA1150 thx

平常心对待！！！

代码不全，估摸着 url 来自于其他地方，抛出错误是合理的，抛出 NPE 不合理

非 java 开发
如果函数参数不允许 null，那么我会在函数开头直接检查
如果为参数 null，立刻报错并结束函数，防止程序执行一半后碰到空指针错误还要回滚操作。
另外代码也能够清晰的表明，函数不允许 null 参数。

不过一般是返回自定义错误，而不是返回 空指针异常

俺寻思着，NPE 还用你抛啊

是为了把所有错误都放在 catch 里处理

搞不懂你们写 java 的点呢[狗头]

打开 V2EX 我久久不能平静。

看完代码，我也久久不能平静，写代码怎么了

哈哈，楼主，现在轮到我们久久不能平静了

实习生写的吧

V 友交流之后应该就平静下来了

没啥毛病啊

没有前面的代码，不知道 try 是为了干什么

非要解释的话也能解释的通,就是能快速把 npe 抛出来,不然还要到真正使用 url 的时候才能抛出 npe,然后 catch ioExcption 这个也没问题,因为 url != null,不代表就不会出现 io 问题

@TmacV2
@xuanbg
@yeqizhang
@ipwx
@wolfie
@guyeu

手机操作容易误操作，蛋疼的很，等我再组织回复

第一，不含任何信息的 NullPointerException，就算是方法开头的参数检验，看起来也是怪怪的，你哪怕弄个 NullPointException("参数：参数名") 也比这强；或者说，裸参数构造的 NullPointerException 包含的信息量太少，要是未预期的由 JVM 抛出还行，要是主动去抛出就显得很不负责任。

第二，＜ try { .... } catch (IOException e) { e.fillInStackTrace(); ＞，这是明显的吃掉异常的行为，非常新手或者不负责任的行为。

我不明白楼主为啥不能平静，不知道槽点在哪？从写法上来说这段代码值得商榷，但是从执行上来说是没问题的
NullPointerException 是运行时异常，IOException 非运行时异常，catch IOException 并不会捕捉到 NullPointerException，仍然会抛给上层，执行起来逻辑是没问题的。
当然，楼主这段代码没有业务逻辑，所以无法判断 throw NullPointerException 是不是合理

@TheWidowMaker #29 java 自带的 Objects.requireNonNull，Guava 的 Preconditions.chechNotNull 都是抛出空指针异常，这俩 API 的设计者都觉得指针是空的抛个空指针就可以，有什么问题呢？

脱离业务上下文单独看，槽点有，但还没到夸张的地步，能用

@mengkun 你这个图可笑死我了

槽点在哪？空指针问题提前抛出来没啥问题啊。

不那么好，但又比用到 url 时自动抛出好一点

看了这个帖子以后，我今天也试了试主动抛出 NPE，感觉可有逼格了。

必须在函数开头检查引用是否为 null，这是最基础的编程常识。这样就可以区分是调用者出了问题，传入了 null，还是函数体有 bug，在中途访问了 null 。bug 就被局限在小范围内，而不是跨函数找 bug 。

除此之外，没有代码上下文，唯一可能出问题的就是把 IOException 掩盖掉的问题。


@guyeu C# visual studio 对传入参数的代码建议也包含 if(x == null) throw new NullReferenceException(nameof(x))，和 java 的思想一致。

错误要早发现早暴露，能在编译器暴露的，就不要等到运行期。就算运行期也要能早暴露尽早暴露。所以一般会在 public 函数开始处做参数校验，抛出业务相关异常；而且应该尽量在 javadoc 注明某参数不接受 null，会抛什么样的异常。

如果不做显式校验，而是使用到这个参数时依靠 jvm 自动报错：
1 、会晚； 2 、是一个业务无关的异常； 3 、随着重构的进行，入参和参数使用的位置可能会很远，甚至不在同一个方法

姑且不谈 try catch，
github 上搜索 throw new NullPointerException，代码有 500 万行，其中很多都是这种写法;
jdk 里面也有这种写法
jdk/src/java.xml.crypto/share/classes/javax/xml/crypto/dsig/dom/DOMSignContext.java
public DOMSignContext(Key signingKey, Node parent) {
if (signingKey == null) {
throw new NullPointerException("signingKey cannot be null");
}
if (parent == null) {
throw new NullPointerException("parent cannot be null");
}
setKeySelector(KeySelector.singletonKeySelector(signingKey));
this.parent = parent;
}
所以你不能平静的点在哪里？

fail early?

检查参数不应该是在方法开头

if (url == null) throw new ArgumentNullException(nameof(url));

么

很多源码不都有这样的判断么