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

• 資深大佬 : 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 很多情况并不需要崩溃的

• 資深大佬 : lxml

  @wuchujie #19 哈哈哈，是我没错了
  go 语言日常操作

  // 从数据库中读一行记录

  xxx ,err := dao.Find()xxx

  // 出现错误错咋办
  if err != nil
  // 处理拿不到的错误
  if err = ErrNotFound
  // 处理其他奇奇怪怪的错误
  else{
  }

  // json 序列化一下，反序列化出错又咋办
  err = Unmarshal()

  求求 go 语言的老大爷们 早点出错误一把梭方案吧，我知道这样写确实能方便处理错误，但是写业务写多了，实在是非常崩溃啊

• 資深大佬 : lihongjie0209

  我担心服务器的内存在某一时刻内存数据受到物理影响被改变了， 怎么办

• 資深大佬 : asj

  说明业务逻辑和数据库存取耦合了。

• 資深大佬 : Takamine

  ……Java 只把异常区分了 checked 和 unchecked，没考虑到突然停电了怎么办。
  :doge:

• 資深大佬 : crclz

  根据业务代码的行为，根据逻辑推演，可以证明：运行到某处，某条件一定成立。（这也是“约定”的数学基础）
  如果某个条件没有被满足，那么就说明它的数学基础不满足：一定是代码有 bug，或者 DBMS 有 bug，或者是有其他未遵守约定的程序（或者人）随意的修改了数据库的记录。

  假设某记录不存在，那么你在访问模型类（假设用 orm ）的成员的时候（也可以主动检查）就会抛出空引用异常，然后就可以查看 log，排查以上三条中的哪一条出了问题。
  站在普通成员的角度，通常只有第一条是你的锅，那么就在业务代码中做足测试，并且在业务代码中加上（适量的）判断约定条件是否成立的语句。

  站在

• 資深大佬 : crclz

  （接上文）
  站在系统负责人的角度，要防御到各方面的因素，那么就请使用 [事件溯源] 模式。

• 資深大佬 : shawnsh

  @wzzzx 我说的是没电机器就不能跑,不能判断下没电也让机器跑吧.