大佬们, 关于 Java 后端空判断

改的没问题，直接 map 提取部门 id 过滤就行

不用纠结这一点，能看懂就行。实际对运行速度没啥影响，结果也是一致的

@oneisall8955 看懂是稍微能看懂, 就是比较纠结, 不知道每次自己写的时候该怎么判断, 判断哪些

因为前面已经过滤 null 了，后续就不需要再检查 null ，所以你改得没啥问题。其次这代码本身就怪怪的，分页查询返回的 List 包括 null 元素（难道是返回固定长度的 List?）

感觉你应该没有太多编程经验，去看这种后台管理项目，去扣它的业务逻辑细节，实际上是走入了误区，想得太多写的太少。这种项目就是用来二次开发的，你自学根本没有实际的需求，看这种只有皮而无肉的空架子代码，那自然会陷入“这里要不要检查 null”，“这里为啥用 Throwable 而不是 Exception”等基本上没啥意义的实现细节。

我的看法是，真正能够有所收获，建立信心的是写自己的项目。你去找一个自己感兴趣且熟悉的领域，找到切入点，写一个至少能用的应用，不需要功能多丰富，实现多完美，至少其是自洽的，麻雀虽小，五脏俱全。比如你的求职目标是 Java 后端，那就去仿一个网站，从需求分析、数据库设计、后端实现、前端实现、应用部署一步步做起，并且去相关垂直领域宣传，给别人使用。

@CLMan 感谢大佬, 主要真的花的时间太多了, 以前都是看黑马和尚硅谷的视频学, 现在去看开源的后台系统感觉比那些视频里教的重复不规范的内容好太多了, 而且我前端没有系统的学习过, 现在前端已经不看了, 现在前端都工程化了, 要学的东西实在太多太多, 我感觉一个 Java 已经耗尽所有精力了

后端肯定要做判空，无论什么时候后端的入参都要校验，这是防御性编程。前端不可靠，你怎么知道用你系统的是人还是机器，数据库是用来保存数据的，如果把判空逻辑放到数据库，那这个系统得烂到什么程度，绝对是个屎山

@vyuai 才这么点就算多????

没写出 30W 行代码别说自己花的时间多

db 里面做了非 null, 去掉 null 判断倒是没啥问题, 就是可能某些代码校验工具里面会报 error 或者 warn.

但如果你不确定 "是否要判断 null", 那就果断判 null 吧, 浪费不了多少效率

前端校验是改善用户体验，可选
后端校验是系统逻辑处理，必选

1. 前端约等于用户输入，永远不要相信用户的输入是正确的，参见测试工程师那个段子；
2. Throwable 有两个子类，Error 和 Exception ，打开 Error 的源文件，注释上明确写了：……because most applications should not try to catch it.（翻译一下：因为大多数应用程序都不应该尝试捕获它），通常我们认为是一些硬件上或者 JVM 的问题，此时程序已经不能正常运行，事务回滚也没什么意义了。

Error 都不提倡捕获，父类 Throwable 就更不应该处理了，所以一般都是直接处理另一个子类 Exception 。

你这套逻辑，加不加这个判空都可以
我的建议是如果你的业务逻辑需要这里的 id 不能为空，就自己加上，不要把这个控制交给数据库
毕竟这个字段不是主键，有可能后续因为什么原因就改成可为空了

这不是可选过滤，这个就不应该过滤。（除非在别人代码加逻辑怕出问题）

万一有人把映射改了，这个字段查不到值了，要第一时间抛出异常，而不是业务逻辑错误。

你定义一个字符串参数,前端传"NULL"串,""串,还有"undefind"串都是常有的事

后端不要怕琐碎 有备无患

没具体看楼主写的内容，单从前后端的 null 判断来说，我不管前端有没有判断 null ，我后端都会判断。因为正常用户会走你的前端页面，非正常用户是直接调用接口的。

前端能校验？有人直接走协议提交参数到后端呢？

一开始我以为是接口对请求参数的非空校验，那这个是很有必要的，避免接受到空值导致后续的业务逻辑出现异常。
但是你图片中的代码，是对数据库返回结果进行非空的过滤，这是我无理解的。

既然是对数据库的查询，那所有的过滤都应该通过 SQL 语句进行，可以利用索引，减少 IO ，分页功能也才准确。

实际开发的时候，因为时间精力的问题，也很难对所有的地方进行非空校验，要不就不会有那么多空指针异常了。
一般情况下，对于服务外输入的值，可以认为是不可信的，做好非空和其他的参数校验。

数据库这种和服务绑定的，可以通过字段属性设置为非空，我是觉得没必要程序里面再加个非空判断。

产生 Error 都是底层问题，你写的 Java 代码无法处理这种问题，一般出现 Error 是建议直接重启进程。

我觉得你这样改是没啥问题的，但如果是挺久之前的旧代码还是不动为好。他这么写的原因可能以前不是必填项，后期改为了必填，也可能代码校验工具提示。老代码性能差距不大的情况下，能用还是别改为好，万一哪天改为非必填呢。

没心情细看。就说问的明确的问题吧。
判空是必须的。代码健壮性要求。鬼知道谁或者哪段代码会调用你的方法 然后给点不正常数据。
补充问题
1 ，都可以用，但是先明白 Throwable Exception 和 RuntimeException 的区别。默认只作用于 RuntimeException 。用哪个看你们的自己的要求。
2 ，以前严谨的都是加外键来确保的，自从互联网开始，就都没了。大不了在代码里去查一下。

前端判断是为了用户体验交互，后端校验是为了保证业务数据稳定，必须要做

数据库为什么不加外键，业务数据的依赖关系都在代码里实现。个人认为，这样做的好处是系统不强依赖数据库，数据库仅仅是数据的存储媒介，没有外键意味着数据库不是存储业务逻辑媒介。方便日后可能会发生的场景：
1. 需求升级，现有库表结构扩展
2. 数据迁移
3. 数据库升级及产品替换

总之，不使用外键，避免牵一发动全身。

所有业务逻辑全部在代码里，那么开发者只要关注代码本身就能知道所有业务逻辑。数据库、redis 、mq 等全部是辅助代码逻辑，系统的业务价值核心在于代码。