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

[ignore]

try { .... if(url == null) { throw new NullPointerException(); } .... } catch (IOException e) { e.fillInStackTrace(); }

[angryfish]

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

[szq8014]

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

[CantSee]

实习生写的吧

[shutan]

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

[shuqin2333]

没啥毛病啊

[uselessVisitor]

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

[unco020511]

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

[passerbytiny]

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

[passerbytiny]

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

[passerbytiny]

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

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

[sdlzqjf]

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

[guyeu]

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

[lwlizhe]

据我所知，能写出这段代码，一般是由项目深厚的历史“底蕴”导致的，盲猜是接手了不知道多少次的代码

[lachesis]

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

[gowk]

@mengkun 你这个图可笑死我了

[Anarchy]

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

[hodur]

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

[SWYou]

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

[crclz]

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

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


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

[nowto]

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

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