2014-09-04 103 views
2

在Django應用程序的settings.py文件中切換DEBUG設置的功能區別是什麼?Django中DEBUG = True和False之間的功能差異是什麼?

我第一次假設DEBUG=True只是打開Django的日誌記錄功能和中間件的錯誤報告,但現在I realize that was naive of me。 瞭解Django內部系統在兩種布爾設置下的工作方式有助於在處理難以調試時形成假設,明文狀態500錯誤

+0

功能上,沒有差異。然而,DEBUG定義了錯誤消息是否應該在瀏覽器級顯示給用戶(DEBUG = True)v/s發送一封電子郵件給管理員(DEBUG =假設有一些設置) – karthikr 2014-09-04 23:33:03

+1

那麼幾十個關於代碼的SO帖子呢* only *使用'DEBUG = True'(例如:http://stackoverflow.com/questions/15128135/setting-debug-false-causes-500-error)?當'DEBUG = True'時似乎更多,否則設置不會破壞代碼工作 - 僅僅以不同的方式報告錯誤。 – ecoe 2014-09-05 13:51:32

回答

1

DEBUG = True的主要優點之一是詳細的錯誤頁面。 Django提供了詳細的堆棧跟蹤。這對調試非常有幫助。基本上,在DEBUG模式下,django會記住它執行的每個SQL查詢(這又使它完全不適合生產)。

此外,如果DEBUG = True,則禁用主機驗證。換句話說,如果DEBUG = False,則需要設置ALLOWED_HOSTS。

+1

謝謝,這絕對是相關的,但我知道必須有更多的事情發生,因爲即使使用'ALLOWED_HOSTS = ['*']'我會看到這500個錯誤。我認爲'DEBUG = True'也會自動糾正代碼的某些方面(但這只是我的猜測,這就是爲什麼我問這個問題的原因) – ecoe 2014-09-06 11:58:41

0

由於Django的1.6.2 it has been identified before那些進口的錯誤不一定陷入DEBUG=True,但肯定是在DEBUG=False

簡單的例子:嘗試導入您的應用程序的settings.pyimport yourapp.settings)到你的意見,然後再重引用不存在的變量:settings.var_that_does_not_exist。這隻會是引用該不存在變量的任何視圖的DEBUG=False時的問題(導致狀態500錯誤)。

相關問題