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

[vyuai]

大佬们, 这种过滤是不是多余的啊, 数据库设计了部门 id 不能为空, 前端也加了校验, 后端还要进行多步的空判断吗, 有点晕了, 一般在什么情况下做这种多步的空判断啊
https://imgur.com/5RXY9q2
以下图片是改造的, 会有什么问题嘛, 是不是到这种程度就可以了
https://imgur.com/jWhJzYu

主要为了学习代码编码风格和规范, 看哪些开源项目比较好啊, 或者看什么别的东西

目前看的是 SmartAdmin 这个开源项目学习, 大佬们有了解的嘛, 看哪位作者的风格比较好呢, 若依实在不喜欢, 目前觉得这个 SmartAdmin 对我帮助很大

补一个问题 Java 后端大部分人都说 CRUD, 企业中 CRUD 到底是什么样子的, 一般一个后端会分多少个表啊, 或者分多少个模块啊, 学到什么程度可以, 一直没有概念, 距离辞职, 已经学习一年了

在补个问题
@Transactional(rollbackFor = Throwable.class)
@Transactional(rollbackFor = Exception.class)
这两种事务回归策略分别在什么情况下使用呢, 看别人代码有的地方 Throwable, 有的地方 Exception, 问 chatgpt 说生产上最好不要使用 Throwable

在补一个问题
https://imgur.com/8k2Yv1M
关系表, 一般不做安全性的判断嘛, 好晕啊, 这个我测试是可以插入脏数据的(数据库中没有的用户 id 和角色 id), 大佬们空的判断一般企业中是什么样子的

[oneisall8955]

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

[oneisall8955]

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

[vyuai]

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

[CLMan]

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

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

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

[vyuai]

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

[iyiluo]

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

[miaotaizi]

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

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

[Shinu]

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

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

[dddd1919]

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

[yuanxiaosong]

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

[yuanxiaosong]

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

[cowcomic]

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

[wolfie]

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

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

[spritecn]

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

[hiveex]

后端不要怕琐碎 有备无患

[DreamingCTW]

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

[249239432]

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

[sadwxds]

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

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

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

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

[cheng6563]

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

[SuperNPC]

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

[ZZ74]

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

[kaf]

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

[woodwhales]

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

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

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