Google 列出的 Cons (of using exception) 第一條和 Joel 的 http://www.joelonsoftware.com/items/2003/10/13.html 差不多意思，而且您先前的文章也包含了相關的部分。

正因為那需要專業程度，換句話說就是犯錯的機會增加了，即使是最優秀的工程師都有可能在狀況差的時候對這些事有所疏忽。於是我的推測是，正如 Google 在文件上寫的，它不想承擔這類型的成本。

另外我也猜測，Google 或許用 code review 和 unit test 從外部來取代某些語言內部機制提供的能力。

你的最後一句話我有不一樣的看法:

像String这种属于基础库的设施，而对于普通的应用开发，如果没有特别的理由，都不应该使用异常。

我的看法是愈是像 String 這種基礎設施, 常常, 愈有機會正確地使用 exception. 因為 call stack 的上上下下大家都在使用, 但能處理錯誤的人卻常不在附近. 回到我在這篇文字中舉的例子, 除了靠近最上層的程序可能有足夠的 knowledge 能 recover 或是對使用者提示錯誤狀況之外, 中間的 code 能拿 String 記憶體請求失敗怎麼辦?

換一個對象來看, 若是針對較特殊應用的”零件”, 像是設置檔的讀寫, 由於被使用/參考的範圍較小, 很容易在接近錯誤出現的地方就能對錯誤加以處理. 例如在讀設置檔時找不到某個欄位的資料 (例如讀不到上一次關閉時視窗的座標) 時, 使用 exception 來回報錯誤就很可能是小題大作了.

我絕對不是在鼓吹 exception 有多好, 即便是用在 String 身上. 例如在這樣的 function 就不適合:

some_integral_type String::FindSubString(const String& sub);

大多數的情況下, 字符串的內容是動態的 (外部輸入的), 找不到一段 sub-string 是執行時期的 input validation 錯誤, 以 error code 方式回報可能更為恰當.