8

What precisely are the functional differences between toggling the DEBUG setting in a settings.py file of a Django app?

I first assumed DEBUG=True merely turned on Django's logging capability and middleware for error reporting, but now I realize that was naive of me. Understanding how the Django internal systems work differently under the two boolean settings helps to form hypotheses when dealing with difficult to debug, plain status 500 errors

Community
  • 1
  • 1
ecoe
  • 4,994
  • 7
  • 54
  • 72
  • Functionally, there are no differences. However, DEBUG defines whether the error message should be shown to the user at the browser level (DEBUG=True) v/s send an email to admins (DEBUG=False with some settings. ) – karthikr Sep 04 '14 at 23:33
  • 2
    what about the dozens of SO posts about code *only* working with `DEBUG=True` (for instance: http://stackoverflow.com/questions/15128135/setting-debug-false-causes-500-error)? It seems more is going on when `DEBUG=True` otherwise that setting wouldn't break code from working - merely report the errors differently. – ecoe Sep 05 '14 at 13:51

3 Answers3

4

One of the main advantages of DEBUG=True is of detailed error pages. Django provides a detailed stacktrace of what went wrong. Which is immensely helpful in debugging. Basically, in DEBUG mode, django remembers every SQL query it executes(Which again makes it totally not suitable for production).

Additionally, if DEBUG=True, host validation is disabled. In other words, if DEBUG=False, ALLOWED_HOSTS needs to be set.

doubleo
  • 4,389
  • 4
  • 16
  • 19
  • 3
    Thanks, this is definitely all relevant but I know there must be more going on because even with `ALLOWED_HOSTS=['*']` I will see these 500 errors. I think `DEBUG=True` also auto-corrects some aspects of the code (but this is just my speculation which is why I asked the question to begin with) – ecoe Sep 06 '14 at 11:58
4
  1. The DEBUG=True, if there is error, page will show details of error.

  2. if DEBUG=False, the ALLOWED_HOSTS of settings.py will work, you should take carefully to set it.

  3. the media and static will not provide access for DEBUG=False, you have to provide them with the help of webserver, like Nginx or Apache.

aircraft
  • 25,146
  • 28
  • 91
  • 166
0

As of Django 1.6.2 it has been identified before that import errors are not necessarily caught in DEBUG=True but certainly are in DEBUG=False

Simple example: Try importing your app's settings.py (import yourapp.settings) into one of your views and then try referencing a non-existent variable: settings.var_that_does_not_exist. This will only be an issue (causing status 500 errors) for when DEBUG=False for any views that reference that non-existent variable.

Community
  • 1
  • 1
ecoe
  • 4,994
  • 7
  • 54
  • 72