有 Bug 潔癖的開發者的福音,如何把你的Bug寫得與眾不同?

當我們寫的一個腳本或程序發生各種不可預知的異常時,如果我們沒有進行捕獲處理的時候,通常都會致使程序崩潰退出,並且會在終端打印出一堆

密密麻麻 的 traceback 堆棧信息來告訴我們,是哪個地方出了問題。

就像這樣子,天吶,密集恐懼症要犯了都


有 Bug 潔癖的開發者的福音,如何把你的Bug寫得與眾不同?


上面這段 traceback

  • 只有黑白兩個顏色,無法像代碼高亮那樣,對肉眼實現太不友好了
  • 無法直接顯示報錯的代碼,排查問題慢人一步,效率太低

那有沒有一種辦法,可以解決這些問題呢?

當然有了,在 Python 中,沒有什麼問題是一個庫解決不了的,如果有,那就等你去開發這個庫。

今天要介紹的這個庫呢,叫做 pretty-errors ,從名字上就可以知道它的用途,是用來美化錯誤信息的。

通過這條命令你可以安裝它

<code>$ python3 -m pip install pretty-errors
複製代碼/<code>

1. 環境要求

由於使用了 pretty-errors 後,你的 traceback 信息輸出,會有代碼高亮那樣的效果,因此當你在使用測試使用 pretty-error 時,請確保你使用的終端可以輸出帶有顏色的字體。

在 windows 上你可以使用 Powershell,cmder 等

在 Mac 上你可以使用自帶的終端,或者安裝一個更好用的 iTerm2

2. 效果對比


隨便寫一個沒有使用 pretty-errors ,並且報錯了的程序,是這樣子的。


有 Bug 潔癖的開發者的福音,如何把你的Bug寫得與眾不同?


而使用了 pretty_errors 後,報錯信息被美化成這樣了。


有 Bug 潔癖的開發者的福音,如何把你的Bug寫得與眾不同?


是不是感覺清楚了不少,那種密密麻麻帶來的焦慮感是不是都消失了呢?

當然這段代碼少,你可能還沒感受到,那就來看下 該項目在 Github上的一張效果對比圖吧


有 Bug 潔癖的開發者的福音,如何把你的Bug寫得與眾不同?


3. 配置全局可用

可以看到使用了 pretty_errors 後,無非就是把過濾掉了一些干擾我們視線的無用信息,然後把有用的關鍵信息給我們高亮顯示。

既然既然這樣,那 pretty_errors 應該也能支持我們如何自定義我們選用什麼樣的顏色,怎麼排版吧?

答案是顯而易見的。

pretty_errors 和其他庫不太一樣,在一定程度上(如果你使用全局配置的話),它並不是開箱即用的,你在使用它之前可能需要做一下配置。

使用這一條命令,會讓你進行配置,可以讓你在該環境中運行其他腳本時的 traceback 輸出都自動美化。

<code>$ python3 -m pretty_errors
複製代碼/<code>


有 Bug 潔癖的開發者的福音,如何把你的Bug寫得與眾不同?


配置完成後,你再運行任何腳本,traceback 都會自動美化了。

不僅是在我的 iTerm 終端下


有 Bug 潔癖的開發者的福音,如何把你的Bug寫得與眾不同?


在 PyCharm 中也會


有 Bug 潔癖的開發者的福音,如何把你的Bug寫得與眾不同?


唯一的缺點就是,原先在 PyCharm 中的 traceback 可以直接點擊 文件路徑 直接跳轉到對應錯誤文件代碼行,而你如果是在 VSCode 可以使用 下面自定義配置的方案解決這個問題(下面會講到,參數是:display_link)。


有 Bug 潔癖的開發者的福音,如何把你的Bug寫得與眾不同?


因此,有些情況下,你並不想設置 pretty_errors 全局可用。

那怎麼取消之前的配置呢?

只需要再次輸出 python -m pretty_errors,輸出入 C 即可清除。


有 Bug 潔癖的開發者的福音,如何把你的Bug寫得與眾不同?


4. 單文件中使用

取消全局可用後,你可以根據自己需要,在你需要使用 pretty-errors 的腳本文件中導入pretty_errors,即可使用

<code>import pretty_errors
複製代碼/<code>

就像這樣

<code>import pretty_errors

def foo():

1/0

if __name__ == "__main__":
foo()
複製代碼/<code>

值得一提的是,使用這種方式,若是你的腳本中,出現語法錯誤,則輸出的異常信息還是按照之前的方式展示,並不會被美化。

因此,為了讓美化更徹底,官方推薦你使用 python -m pretty_errors

5. 自定義設置

上面的例子裡,我們使用的都是 pretty_errors 的默認美化格式,展示的信息並沒有那麼全。

比如

  • 它並沒有展示報錯文件的絕對路徑,這將使我們很難定位到是哪個文件裡的代碼出現錯誤。
  • 如果能把具體報錯的代碼,給我們展示在終端屏幕上,就不需要我們再到源碼文件中排查原因了。

如果使用了 pretty_errors 導致異常信息有丟失,那還不如不使用 pretty_errors 呢。

不過,可以告訴你的是,pretty_errors 並沒有你想象的那麼簡單。

它足夠開放,支持自定義配置,可以由你選擇你需要展示哪些信息,怎麼展示?

這裡舉一個例子

<code>import pretty_errors

# 【重點】進行配置
pretty_errors.configure(
separator_character = '*',
filename_display = pretty_errors.FILENAME_EXTENDED,
line_number_first = True,
display_link = True,
lines_before = 5,
lines_after = 2,
line_color = pretty_errors.RED + '> ' + pretty_errors.default_config.line_color,
code_color = ' ' + pretty_errors.default_config.line_color,
)

# 原來的代碼
def foo():
1/0

if __name__ == "__main__":
foo()
複製代碼/<code>

在你像上面這樣使用 pretty_errrs.configure 進行配置時,拋出的的異常信息就變成這樣了。


有 Bug 潔癖的開發者的福音,如何把你的Bug寫得與眾不同?


當然了,pretty_errors.configure() 還可以接收很多的參數,你可以根據你自己的需要進行配置。

5.1 設置顏色

  • header_color:設置標題行的顏色。
  • timestamp_color:設置時間戳顏色
  • default_color:設置默認的顏色
  • filename_color:設置文件名顏色
  • line_number_color:設置行號顏色。
  • function_color:設置函數顏色。
  • link_color:設置鏈接的顏色。

在設置顏色的時候,pretty_errors 提供了一些常用的 顏色常量供你直接調取。

  • BLACK:黑色
  • GREY:灰色
  • RED:紅色
  • GREEN:綠色
  • YELLOW:黃色
  • BLUE:藍色
  • MAGENTA:品紅色
  • CYAN:藍綠色
  • WHITE:白色

而每一種顏色,都相應的匹配的 BRIGHT_ 變體 和 _BACKGROUND 變體,

其中,_BACKGROUND 用於設置背景色,舉個例子如下。


有 Bug 潔癖的開發者的福音,如何把你的Bug寫得與眾不同?


5.2 設置顯示內容

  • line_number_first 啟用後,將首先顯示行號,而不是文件名。
  • lines_before : 顯示發生異常處的前幾行代碼
  • lines_after: 顯示發生異常處的後幾行代碼
  • display_link:啟用後,將在錯誤位置下方寫入鏈接,VScode將允許您單擊該鏈接。
  • separator_character:用於創建標題行的字符。默認情況下使用連字符。如果設置為 '' 或者 None ,標題將被禁用。
  • display_timestamp:啟用時,時間戳將寫入回溯頭中。
  • display_locals 啟用後,將顯示在頂部堆棧框架代碼中的局部變量及其值。
  • display_trace_locals 啟用後,其他堆棧框架代碼中出現的局部變量將與它們的值一起顯示。

5.3 設置怎麼顯示

  • line_length:設置每行的長度,默認為0,表示每行的輸出將與控制檯尺寸相匹配,如果你設置的長度將好與控制檯寬度匹配,則可能需要禁用full_line_newline,以防止出現明顯的雙換行符。
  • full_line_newline:當輸出的字符滿行時,是否要插入換行符。
  • timestamp_function 調用該函數以生成時間戳。默認值為time.perf_counter。
  • top_first 啟用後,堆棧跟蹤將反轉,首先顯示堆棧頂部。
  • display_arrow 啟用後,將針對語法錯誤顯示一個箭頭,指向有問題的令牌。
  • truncate_code 啟用後,每行代碼將被截斷以適合行長。
  • stack_depth 要顯示的堆棧跟蹤的最大條目數。什麼時候0將顯示整個堆棧,這是默認值。
  • exception_above 啟用後,異常將顯示在堆棧跟蹤上方。
  • exception_below: 啟用後,異常顯示在堆棧跟蹤下方。
  • reset_stdout 啟用後,重置轉義序列將寫入stdout和stderr;如果您的控制檯留下錯誤的顏色,請啟用此選項。
  • filename_display 設置文件名的展示方式,有三個選項: pretty_errors.FILENAME_COMPACT 、pretty_errors.FILENAME_EXTENDED,或者pretty_errors.FILENAME_FULL

以上,就是我對 pretty_errors 的使用體驗,總的來說,這個庫功能非常強大,使用效果也特別酷炫,它就跟 PEP8 規範一樣,沒有它是可以,但是有了它會更好一樣。對於某些想自定義錯誤輸出場景的人,pretty_errors 會是一個不錯的解決方案


作者:王一白
鏈接:https://juejin.im/post/5e662a23518825495a278714
來源:掘金
著作權歸作者所有。商業轉載請聯繫作者獲得授權,非商業轉載請註明出處。

最後,小編想說:我是一名python開發工程師,

整理了一套最新的python系統學習教程,

想要這些資料的可以關注私信小編“01”即可(免費分享哦)希望能對你有所幫助


分享到:


相關文章: