現在的語言提供異常處理語句，try/throw，不過我很少用這個，覺得沒什麽用。我寫程序對出錯的處理，通常是盡量檢測出可能出錯的情形，在代碼中預防，不讓它出現，而對代碼無法預防的錯誤，實際上也是沒有很好處理辦法的，衹能如舊式系統那樣，體面地退出了事，報告錯誤原因。C++11標準，其實也坦白沒有很好的處理辦法，發佈了允許限制彈出異常的關鍵字，主要原因有兩個，一個是異常機制從資源和時間上來說都消耗很大（大多數時間都能感受到彈出前的呆滯），另一個是異常之後基本上是很難返回原始現場的繼續的（能夠通過代碼返回的，都可以事先設計預防不致彈出異常）。比如像内存耗盡這類，根本是彈出異常也是沒卵用了；再如文件無法打開，沒有權限就怎麽處理也沒用，有些情景也不是文件不存在你就可以自作主張替用戶生成一個的；這些都不好處理，分支了也沒用。

[此贴子已经被作者于2015-11-5 11:42编辑过]

一個很典型的例子：交互式輸入界面，像gets()這類通過用戶自己按鍵輸入的方式，很難防止錯誤，所以人們發明了諸如下拉框這類界面，就是爲了限制用戶隨便輸入的可能性，比純粹靠異常機制穩妥。這種複雜界面的開發，不是爲了好看的，而是有實際需要的，當然，這做多了許多事。

能避免的错误尽量避免，但是用户传入的数据有可能错误，还有难免会保证自己的代码完全没错，一般用日志记录不平常的错误，以后出问题了，看日志可以大大加快找bug的效率。（一般错误了，我也会把出错的数据或内存记录到日志，以便重现错误）。就比如内存不足，如果只是自己的代码引起的，那要么是自己的代码有BUG，要么是设计有问题。合适的日志可以很快找到程序的问题，比如用宏实现malloc,free,可以记录内存分配情况，很容易找到是不是有无意识到的内存泄漏。

嗯，能記錄得到原始情形是不錯的。

當malloc()失敗的時候，後面的動作未必可以完成，寫日志文件本身就要申請資源，此時既然malloc()都不行了，再請求也同樣不行，何況，記下來的也未必可以重現和有用，因爲像malloc()這樣的動作，是隨著程序運行積纍出來的，每次運行都不同。

就我自己的實踐經驗來說，衹能是“盡量避免出錯”，第一通過設計和代碼提前預防，第二是不斷地終身地維護。

[此贴子已经被作者于2015-11-5 12:37编辑过]

写个日志，用堆栈里的空间足够了，64字节已经足了。Windows下我不知道，linux下肯定是可以的。

[此贴子已经被作者于2015-11-5 12:51编辑过]

即使你不开swap,linux下即使不行，可以修改内核自己重新生成一个可以的内核。

日志不是万能的，不可能发现所有代码的BUG和设计没考录到的问题，但可以极大提高调试程序和发现BUG的效率。比如说malloc,free的日志一般的内存泄漏可以发现的，在比如代码中所有的边界越界都记下日志，绝大部分的内存访问违例也容易发现(不用调试器)。这些处理机制都是用宏来实现，在正式版本下把它们去掉又不会影响性能。

我一向是直接調試release版本的代碼

我已经说了问的是goto的用法啊，我把else 和exit注释掉了，问题还是一样。