異常安全性
異常安全保證有3種：
(a)
基本保證：保證不會發生資源洩露，即使操作失敗；但是狀態可能發生改變。
(b)
強保證：事務提交
/回滾語義
。即使操作失敗也不會導致程式狀態改變。
(c)
無失敗保證：不允許失敗發生。即絕對不會拋異常。
準則：函式應該總是支援它所能支援的最強的異常安全保證，但是前提是不能給那些並不需要該保證的呼叫者帶來額外的開銷。
準則：永遠不要允許析構函式
(deconstruct)
、釋放操作
(deallocation)
和swap()
函式丟擲異常，否則的話，就沒法安全且可靠地進行資源清理了。這是事務程式設計的基本前提，沒有這些保證，無法確保事務提交和回滾不會失敗。
編寫異常安全**的幾條建議：
1) 使用「資源獲取即初始化
(raii
，特指c++
的構造和析構函式
)」慣用法來管理資源的所有權。如果獲取失敗，就釋放資源，這可以防止資源洩露，還可以防止未初始化錯誤。
2) 使用「先在一旁將所有的事情做完，然後再通過不拋異常的操作來提交整個任務 」的手法，避免在不確定所有操作能否成功的情況下貿然去改變物件的內部狀態。這就是事務性程式設計，常用於保證強保證。
3) 盡量使用「單一職責的類或函式」。完成多件事情的函式是很難（無法）實現強異常保證的。比如
stack
的pop
具有取值和出棧兩功能，由於
stack
可以用於儲存物件（臨時變數），而物件
(非內建型別
)的任何操作
(對外介面或運算過載
)都是可能拋異常的
，要實現異常安全非常困難。
參考書：exceptional c++， exceptional c++ style
rust提示遊戲安全違規 7 1 異常安全性
異常 exception 安全性 雖然前面說過我們應該慎用展開，但是還是有許多的地方會panic。如果你對none呼叫unwrap 使用超出範圍的索引值 或者用0做除數，你的程式就要panic。在debug模式下，所有的計算操作在溢位的時候也都會panic。除非你十分小心並且嚴格控制著每一條 的行為...
C 安全性之一
安全性 每次寫c 的文章，總免不了要批判一下c 這篇文章也不例外。通過上面的講述，相信我們對虛函式表有乙個比較細緻的了解了。水可載舟，亦可覆舟。下面，讓我們來看看我們可以用虛函式表來幹點什麼壞事吧。一 通過父型別的指標訪問子類自己的虛函式 我們知道，子類沒有過載父類的虛函式是一件毫無意義的事情。因為...
多執行緒讀操作的異常安全性
最近在寫乙個專案，程式偶現乙個 double free 問題，經過排查發現在實際運 況中會有多個執行緒呼叫乙個loadstring操作，而原本loadstring只是乙個讀操作，而多執行緒共同讀同乙個資源資訊按理說應該是不會有同步問題出現的，但是通過gdb除錯發現程式的崩潰處在switchlangu...