前序
对于程序员来说，遇到NPE场景应该算是很正常的情况了。不管是在本地开发环境或者是在测试环境，总是会时不时的遇到NPE场景。其实遇到NPE场景并不可怕，相对于程序一些其他异常来说，NPE异常属于众多异常中最容易排查，最容易定位问题，也最容易解决的异常场景。当然也不能说是因为NPE异常问题容易处理，你就可以放心的造BUG，你要知道，往往容易排查的异常场景，往往也就最不应该出现，出现的很大原因在于开发者的不细心。
NPE场景
虽然说NPE场景容易排查容易解决，但是在Java编程实践中，空指针异常（NPE）是开发过程中常见的障碍，它不仅阻碍了代码的正常运行，还常常成为系统不稳定性的根源。那么如何识别那些潜藏于代码深处的NPE触发场景？
先来说说NPE 空指针异常...
NPE
可以说，在日常开发中或多或少的都会遇到NPE的场景，即便你在开发过程中很谨慎，但是导致NPE的场景并不完全是由代码决定的，也可能是数据导致的。
通常情况下触发NPE的场景比如你没有初始化对象，但是直接调用该对象取参数就会报NPE，比如
或者是你调用的方法在未查询到数据时直接返回null，但是在后续的逻辑处理中并没有对对象判空导致再取属性值时报NPE
或者是你的代码中需要获取外部资源，包括但不限于下载图片读取图片内容等操作，那么由于网络导致获取图片内容失败时，此时再处理图片内容就会报NPE。
如何处理NPE
其实代码开发过程中遇到NPE并不可怕，关键是如何去处理这些NPE。你可以选择在功能开发完成之后通过单元测试来测试代码的健壮性。
你也可以在开发过程中通过增加非空判断来提升代码质量，任何口头的说数据库中某条数据一定存在，或者某个字段一定存在都不可信，在你的功能逻辑中如果遇到取值的情况，先判空再取值，没毛病。
当然也可以借助外部代码审核工具，比如常用的 FindBugs 来帮助你排除基础的代码错误，包括NPE的情况。或者你也可以团队之间相互审核对方代码，从而来避免可能发生的NPE情况。
为了防止NPE引发的程序执行失败或者程序崩溃，适当的引入try catch捕获异常进行后续处理逻辑也是可行的。当然 try catch并不是适用所有的场景，有的场景当发生NPE时，确实需要程序无法执行下去，这个时候就不能使用 try catch 来处理异常，而是需要抛出异常显现问题。
总之，关于NPE的问题，除了在开发过程中尽量丰富自己的代码逻辑外，还需要通过代码审查，外部工具等方式来进行排查，从而挖出潜藏的NPE问题，将一切问题都暴露在上线前，保证系统的稳定运行。
