エラーハンドリングをミスって大事故に - Qiita

はじめに アドベントカレンダー初参加です！ とある企業でサーバーサイドエンジニアとして働いており、主にGoでAPIを実装しています。 今年に入って新規事業の開発を任され、色々やらかしを経験させていただきました。 その中でも一番のやらかしを自戒の念も込めて投稿したいと思います。 特定を避けるために敢えて分かりづらく表現している箇所があります。その点ご了承くださいmm 惨劇発覚前夜 とある会員制サイトのリリースを控えており、それに備えて色々準備を整えてました。 リリース当日はそれなりにアクセス急増が見込まれるので ALBの暖気申請 フロントエンドサーバーのスケールアウト 等の対応を行いました。 今までも似たようなサイトをいくつかリリースしており、上記の対応でアクセスは捌けていたので今回も同様の対応で問題ないと思ってました。 リリース当日PM20:00 にサイトのURLを公開。 今までをはるかに

[pmint]

よく読むとデッドロックは問題じゃないらしい。ユニークなIDを更新するUPDATE文も普通じゃない。この記事自体がよく読まないと論旨が分からない文章になってるし、問題の実体は別にありそう。

[turanukimaru]

普通Updateだけで重複はしない…一人のユーザの情報が複数できてしまったのかな？多分会員情報変更履歴作ろうとしてミスってるな。なお名前付き戻り値使う派なのだが事故りそうなときはIntelliJが警告を吐くので安心。

[mattn]

僕は named return values は極力使わない様にしてる。

[daira4000]

テストを怠った話じゃなくて？

[tmatsuu]

あー。err変数のスコープ問題はここまでの惨劇ではないけど自分も経験ある。ついやっちゃいがち。自分ならifの中で直接 `return nil, err` って書いちゃうね。名前付き戻り値はあまり使わないようにしてる。

[stakme]

私もGo書いてて疑問なんですけど「戻り値が名前付きerr」だと意図せず操作されがちで危険じゃないですか？もっと長い名前、たとえばrtnErrにするとか、名前つけるの自体やめてその場でreturn errのほうが安全そうな気が

[hasiduki]

lintツールが怒らないの?

[rryu]

同じようなやつでRailsのActiveRecordで自オブジェクトのカラムに値をセットしているつもりが実はローカル変数に代入していたという罠にはまったことがある。

[daichirata]

名前付き戻り値は if でハンドリングとかせずそのまま代入して return するくらい単純な関数でだけ使うこともあるくらい

[kanehama]

UNIQUE KEYが戦犯

[shioki]

“テーブル内で重複させたくないカラムにはUNIQUE KEYを付与する なぜこれを事前にやってなかったかは過去の自分に問いたいです”

[zentarou]

名前付き戻り値は使わないな

[igrep]

静的解析でなんとかならんの、と思いきや試した限りはならんらしい。うーむ。