曾經在面試的時候，面試官問了一句：如果App發布以后，用戶在使用的過程中出現崩潰、卡頓或者錯誤，你是怎么處理的？
當時我就按常規思路回答了這個問題，無非就是在App中提供意見反饋、留下聯系方式之類的廢話，顯然沒有回答到問題的點子上，自己也意識到回答得有點勉強。試想有多少用戶愿意在App出現故障后專門給你發送信息反饋，然后還要別人留下聯系方式讓你騷擾他？
出現這樣的情況，當然要去反思一下，當時我就去翻看了時下流行的App，其中微信的處理方式是列出常見的問題，分功能模塊的去細分可能出現的問題，只需要用戶點擊選擇就可以進行反饋，這樣至少不會太讓用戶產生太大的反感情緒。另外我猜想微信這樣處理的背后還有自己的Bug詳細信息收集系統，將產生的Bug文件保存在本地，在必要的時候再上傳到Bug收集系統的服務器上去。
但一般的小公司哪有這個精力和成本去設計這樣的Bug體系呢？沒關系，其他公司已經考慮到了這樣的問題，友盟、Bugly等服務平臺已經基本上可以滿足Bug收集的要求了，我們在開發的時候接入他們提供的SDK即可，在App出現異常錯誤的時候，App就會將產生的異常錯誤實時上傳到已注冊的平臺上去，簡單方便。
以Bugly為例，我們可以看到App上傳的Bug信息，一目了然，所產生的信息和我們在代碼調試時產生的異常提示相似，雖然這樣不能及時地讓我們精確判斷問題的位置所在，待至少給我們提供了一個解決問題的思路，我想這已經足夠了。
如果我們在自己內部測試的時候，每次都去服務平臺上查看Bug信息，太費事。那么Apple給我們提供了一種方式：
NSSetUncaughtExceptionHandler (&UncaughtExceptionHandler);
其中，UncaughtExceptionHandler是一個函數指針類型，所指向的函數需要我們實現，可以取自己想要的名字。當程序發生異常崩潰時，該函數會得到調用，這跟C，C++中的回調函數的概念是一樣的。
