我正在為某個主機應用程式開發一套插件，針對 Windows 和 Mac (OSX )。插件是用 C 撰寫的。我想為他們添加崩潰和例外報告處理，以防插件失控。這是為了在插件行為不端的情況下不讓整個主機應用程式崩潰，而是獲得一些反饋，然后跳過那個插件呼叫（并使后續插件呼叫成為一種無操作）。考慮記錄一些狀態并在其上添加錯誤代碼 文本。從那時起，插件切換到錯誤狀態，請求詳細資訊會回傳此狀態。
這是一個很大的遺留代碼庫，隨著時間的推移已經有了很大的改進，但是這里和那里仍然有一些粗糙的邊緣，所以像“不要崩潰”這樣的答案不是我想要的:)它也沒有t 幫助我更像是一個 Windows 開發人員而不是 macOS 開發人員，所以我可能忽略了一些完全顯而易見的事情。
- 我通過在插件入口點將每個主機->插件回呼包裝在一個大的 C try/catch 塊中，以跨平臺的方式覆寫了未處理的 C 例外。
- 通過使用 __try/__except 并注冊 SEH 處理程式，我還在同一地點為 Windows 處理崩潰、除零、訪問沖突等。
- 現在我也想為 Mac 做后者。但是在這里，我正在努力找出我的選擇是什么，如果有的話。
我研究了信號處理程式，但我從中了解到它們是行程范圍的。即：不是插件友好的，特別是當主機可以同時使用多個這些插件時（誰將首先捕獲并處理信號？）。并且宿主應用程式已經有它自己的崩潰處理程式，可能使用信號處理程式，所以安裝我們自己的會導致我認為誰負責？另外，我的報告選項在此類處理程式中極為有限；如果可能的話，我想在這里有更多的自由（比如將 std::strings 與他們暗示的 new/delete 一起使用）。
然后還有馬赫例外處理。但是在結合“插件”進行谷歌搜索時，我完全無法獲得資訊豐富的結果......
有沒有人對走哪條路線有任何建議，或者在我的情況下哪種選擇更好？
uj5u.com熱心網友回復：
macOS 上的唯一選項是信號處理程式和馬赫例外處理程式。
這兩種機制都是行程范圍的，因此無論何時出現問題都會報告問題。
如果安裝了新的信號處理程式，則不會運行舊的信號處理程式。該sigaction()API 確實會回傳以前安裝的 API，因此它可以與您的新 API 一樣運行。然后可能會再次安裝另一個信號處理程式并替換您的信號處理程式。
這里有一篇非常有用的帖子，詳細介紹了實作信號處理程式 - https://developer.apple.com/forums/thread/113742
Mach 例外處理程式的情況幾乎相同，呼叫task_set_exception_ports()將覆寫先前設定的處理程式，因此如果您想傳播例外，則必須在新處理程式運行后恢復這些處理程式。Mach 例外處理程式的一大優勢是它們可以在單獨的行程中運行，您可以在其中自由使用 std::strings 等，但代價是檢查崩潰行程的狀態更加困難。
關于 Mach 例外處理的檔案很少，最好的參考是各種開源崩潰報告框架。
總的來說，很難正確實作崩潰檢測，我建議不要在插件中這樣做。它比 SEH 復雜得多。
轉載請註明出處，本文鏈接：https://www.uj5u.com/caozuo/431600.html