Stay Ahead with the Power of Upskilling - Invest in Yourself! 
During development, being able to see tracebacks and errors live in your browser is extremely useful. Django has “pretty” and informative debug messages specifically to make debugging easier.However, if these errors get displayed once the site goes live, they can reveal aspects of your code or configuration that could aid an attacker.
Furthermore, errors and tracebacks aren’t at all useful to end users. Django’s philosophy is that site visitors should never see application-related error messages. If your code raises an unhandled exception, a site visitor should not see the full traceback — or any hint of code snippets or Python (programmer-oriented) error messages. Instead, the visitor should see a friendly “This page is unavailable” message. Naturally, of course, developers need to see tracebacks to debug problems in their code. So the framework should hide all error messages from the public, but it should display them to the trusted site developers.
The Solution – Django has a simple flag that controls the display of these error messages. If the DEBUG setting is set to True, error messages will be displayed in the browser. If not, Django will render return an HTTP 500 (“Internal server error”) message and render an error template that you provide. This error template is called 500.html and should live in the root of one of your template directories.
Because developers still need to see errors generated on a live site, any errors handled this way will send an email with the full traceback to any addresses given in the ADMINS setting. Users deploying under Apache and mod_python should also make sure they have PythonDebug Off in their Apache conf files; this will suppress any errors that occur before Django has had a chance to load.
