相比其它編程語言，Python 輸齣錯誤 異常提示信息算是比較齊的。
萬事無絕對，世上本無完美的事物，仍需對異常作進一步的處理。
注意，少用以下代碼處理異常：
try:
do some thing
except:
pass
try:
do some thing
except Exception:
pass
由於這會捕獲所有異常，因此，抑製瞭源代碼的所有功能性不足 Bug，不利於後期調試。
以下是一些 Python 錯誤 異常常見解決辦法或策略：
采用專有進程批量采集，所有可能的錯誤 異常 一般信息。
之後再過濾齣錯誤 異常，一條條加以手動修正。
此方式同常用編程，log 文件功能類似。
隻是添加瞭自動化過濾能力，且進程獨立。
某些錯誤 異常無法避免且偶爾齣現，可在適當位置輸齣其提示信息。
若有可能的話，後期想辦法解決；有些問題，可能一時或永遠無法解決 (或找到解決辦法)。
由於提示信息被輸齣到調試後端，對用戶而言不可見；盡可能通過批量采集獲取，方便後期分析錯誤 異常提示原因。
某些異常無法避免且較少齣現，可嚮用戶強製展示信息提示對話框。
若有可能，後期再想辦法解決。
某些異常是很難解決的，或由無法避免的外部原因導緻。
注意：可嚮用戶強製展示這些異常，增強用戶對應用程序的理解 信任，參與異常的解決過程。
由於應用程序設計缺陷、不當參數、編程語言無法理解的語法 變量、編程語言的設計缺陷、等原因造成的異常。
這種異常可能沒有提示信息 (或信息不足)，如閃崩、卡死、內存突然大幅升高、有規律性的偶爾齣錯、等等。
注意：無聲漏洞本身並非完全無聲，包括：調試方法不對、調試者沒注意到、應用場景不當或沒找到調試入口。
譬如：應用已退齣來不及輸齣異常提示、異常代碼目前不使用、上下文關係不明確、 縮進錯誤不明顯。
無聲漏洞要花不少時間來解決，需開發者本人、對應用場景理解很深的人或行業專傢的深度參與。
此類異常要徹底解決 (或改良)，否則，彆說影響用戶體驗，可能連正常使用都成問題。
若某一問題長時間無法被解決且對用戶體驗影響極差，此應用程序完瞭。
要體現一個程序員的水平，也就是修正此類問題。
在編寫源代碼時，存在各種考慮不周的異常很正常。
源代碼異常，由開發者解決最好。
對於開源軟件，使用者可以自已想辦法解決。
若是閉源軟件，在沒有參考資料的情況下，一般很難解決。
當源代碼存在嚴重且難於修正的異常時，可采用多版本或多種 IDE、多種編譯 打包 分發工具、等作為測試入口調試。
可測試整個工程、單模塊、單功能，甚至對每個函數、每行代碼進行原子化調試。
同樣是 Python 技術，在 CPython Cython PyInstaller 下是有差異的。
不同的 CPython 版本之間，也有一些差異。
對於多入口調試，進行單工程 多版本 柔性 並行開發，是有必要的。
比較式開發，便於找齣不同版本之間的共性 差異；特彆是將工程分為源代碼版、調試版、發布版、新版、舊版、穩定版等。
如僅將 Python 2.7 (存在很多現成技術 參考資源) 作為比較參考源，3.4 3.5 3.6 之後的版本隻要穩定、操作係統 (或用戶和應用場景) 支持，都可以並行推進。
多版本柔性 並行開發不能要求所有版本權重都一樣，相對傳統 IDE，推薦使用 數字 IDE 。
開發新功能源代碼時，開發效率、調試時間及調試頻率要適當。
開發很多新功能卻很少調試或調試時間花費少，有時會産生意料不到的情況或 Bug。
尤其當齣現程序架構、開發邏輯、編程語言、新舊框架或編譯器兼容性導緻的無聲漏洞，調試時會很頭痛。
這也是 Python 為什麼比 Java C/C++ 等編程語言先天性存在開發優勢的原因，編寫更少的代碼卻能獲得更多的功能。
相同功能下 Python 源代碼量隻有 C/C++ 代碼量的 20 - 30%，當使用 Cython 編譯器 把 Python 代碼轉換成 C 語言中間代碼時就能看到。
另請參閱：
PySide2 PyQt5 錯誤異常 調試漏洞 疑難雜癥 解決辦法匯總
版權聲明： 本文為獨傢原創稿件，版權歸 樂數軟件 ，未經許可不得轉載。