在作数据库的读写操作时大家有没过一种奇怪的焦虑感？

[webcoder]

明明系统里已经约定了，运行到某个代码前数据库里肯定会有这个记录，但写的时候总有种这记录可能不存在的焦虑而会写上一大堆的校验检查甚至是如果不存在就创建的代码，而且在写时还会有种这代码正式使用时估计一辈子也不可能运行到的感觉，从而进化成，既然运行不到为什么还要写啊，的奇怪情绪。

[xiaotuzi]

这是代码的严谨性。

[liuzhedash]

写好抛异常，抓日志的代码就行。
如果系统设计这个点是应该存在记录的，那有日志不管定位还是甩锅都方便；如果系统设计没有明确这个点，最好提前明确，否则就是定位困难+甩锅大战。

[shawnsh]

不要这样写冗余代码。检查不符合条件直接崩溃

[opengps]

这里要说的是任何代码都进行异常捕获的重要性！

[billlee]

assert 就行了

[crazytudou]

以前也会考虑这些，现在。。不考虑，只有给对才执行下去，不对就抛异常，这个很有好处，1 是可以知道程序不对要改正，2 是不用再去写一堆感觉没用的东西，这个严谨无关吧

[laminux29]

1.检查代码肯定要写。

2.如果不符合约定，则先写日志，后抛异常。

[guyeu]

在该 crash 的时候 crash，不要做不该做的容错。

[guokeke]

会写。因为没什么是肯定的。

[Mohanson]

分清楚"异常"和"错误". 异常是预期会发生的, 而错误是预期不会发生的. 遇到错误就 crash 掉方为正手.

[GrayXu]

约定了就不管啊。。本地日志记得说明下就好了

[whalegao]

考虑主从同步了吗。

[sun1991]

如果记录不存在会导致直接 crash 的就可以不管. 否则检查条件并手工 crash. (不过有时候我会偷懒~)

[xavierchow]

> 会写上一大堆的校验检查甚至是如果不存在就创建的代码

你需要明确你的模块的接口和职责，我猜测你的焦虑是由于对接口定义的不清晰， 另外不存在就创建很容易掩盖其他地方的错误，造成后期问题定位的更大问题。
可以看一下 [fail fast]( https://en.wikipedia.org/wiki/Fail-fast)。
另外你这些所谓的多余的代码有测试代码吗？能在测试环境跑过吗？不要去写不可测的代码，因为你不知道你所谓的多加的处理是否正确。（尽管你本意是让系统更 robust,但是增加复杂度和降低可读性来换取不知正确性的容错处理得不偿失）

[FrankHB]

正常是看到 DBMS 就有焦虑感。只不过业务上抖 M 惯了很多人才没感觉罢了。
这和所谓防御性编程贩卖的焦虑本质上是一样的，虽然就影响范围来讲，往往更严重。
本来是系统内部的 contract，因为 DBMS 和上层业务逻辑的隔离多了一个间接层，因为实现缺陷的问题导致你不得单独考虑风险。这不但让你有焦虑感，一定情况下还成为一个 attack surface。在 DBMS 不是最终用户需要感知的实现细节的情况下，这就是歪曲系统需求的原罪。
很遗憾，如何有效地、系统地尊重准确地表达需求而不弱化外部指定的整体接口约束，这是一个从理论 CS 开始一直就缺乏足够重视一直到头疼医头脚疼医脚也还没解决的问题。工业界的某些人刚刚才认识到 artificially widening narrow contracts considered harmful。理论界这方面整体反而更呵呵就是了。这应该是这里的人都推动不了的；所以你如果干不掉 DB，继续忍几十年好了。

[JJstyle]

如果是 laravel 项目，建议用 findOrFail 方法代替 find，这个函数在找不到数据时直接抛异常，而不是返回 null，免得后面还去判断取得的数据是不是 null

[xiaozoom]

这种焦虑我理解。
“运行到某个代码前数据库里肯定会有这个记录”
在我看来，这真的没法肯定的，原因可能会有多方面的，比如换人维护了，又比如后来维护的人根本没时间弄懂前面的代码就开始改后面的部分（亲身经历）。

[yafoo]

有同样焦虑

[wuchujie]

go 写多了吗

[wzzzx]

@shawnsh #3 @shawnsh #3 很多情况并不需要崩溃的