mirror of
https://github.com/django/django.git
synced 2025-08-04 19:08:28 +00:00
Massive reorganization of the docs. See the new docs online at http://docs.djangoproject.com/.
git-svn-id: http://code.djangoproject.com/svn/django/trunk@8506 bcc190cf-cafb-0310-a4f2-bffc1f526a37
This commit is contained in:
parent
b3688e8194
commit
97cb07c3a1
188 changed files with 19913 additions and 17059 deletions
65
docs/howto/error-reporting.txt
Normal file
65
docs/howto/error-reporting.txt
Normal file
|
@ -0,0 +1,65 @@
|
|||
.. _howto-error-reporting:
|
||||
|
||||
Error reporting via e-mail
|
||||
==========================
|
||||
|
||||
When you're running a public site you should always turn off the
|
||||
:setting:`DEBUG` setting. That will make your server run much faster, and will
|
||||
also prevent malicious users from seeing details of your application that can be
|
||||
revealed by the error pages.
|
||||
|
||||
However, running with :setting:`DEBUG` set to ``False`` means you'll never see
|
||||
errors generated by your site -- everyone will just see your public error pages.
|
||||
You need to keep track of errors that occur in deployed sites, so Django can be
|
||||
configured to email you details of those errors.
|
||||
|
||||
Server errors
|
||||
-------------
|
||||
|
||||
When :setting:`DEBUG` is ``False``, Django will e-mail the users listed in the
|
||||
:setting:`ADMIN` setting whenever your code raises an unhandled exception and
|
||||
results in an internal server error (HTTP status code 500). This gives the
|
||||
administrators immediate notification of any errors. The :setting:`ADMINS` will
|
||||
get a description of the error, a complete Python traceback, and details about
|
||||
the HTTP request that caused the error.
|
||||
|
||||
To disable this behavior, just remove all entries from the :setting:`ADMINS`
|
||||
setting.
|
||||
|
||||
404 errors
|
||||
----------
|
||||
|
||||
Django can also be configured to email errors about broken links (404 "page
|
||||
not found" errors). Django sends emails about 404 errors when:
|
||||
|
||||
* :setting:`DEBUG` is ``False``
|
||||
|
||||
* :setting:`SEND_BROKEN_LINK_EMAILS` is ``True``
|
||||
|
||||
* Your :setting:`MIDDLEWARE_CLASSES` setting includes ``CommonMiddleware``
|
||||
(which it does by default).
|
||||
|
||||
If those conditions are met, Django will e-mail the users listed in the
|
||||
:setting:`MANAGERS` setting whenever your code raises a 404 and the request has
|
||||
a referer. (It doesn't bother to e-mail for 404s that don't have a referer --
|
||||
those are usually just people typing in broken URLs or broken web 'bots).
|
||||
|
||||
You can tell Django to stop reporting particular 404s by tweaking the
|
||||
:setting:`IGNORABLE_404_ENDS` and :setting:`IGNORABLE_404_STARTS` settings. Both
|
||||
should be a tuple of strings. For example::
|
||||
|
||||
IGNORABLE_404_ENDS = ('.php', '.cgi')
|
||||
IGNORABLE_404_STARTS = ('/phpmyadmin/',)
|
||||
|
||||
In this example, a 404 to any URL ending with ``.php`` or ``.cgi`` will *not* be
|
||||
reported. Neither will any URL starting with ``/phpmyadmin/``.
|
||||
|
||||
The best way to disable this behavior is to set
|
||||
:setting:`SEND_BROKEN_LINK_EMAILS` to ``False``.
|
||||
|
||||
.. seealso::
|
||||
|
||||
You can also set up custom error reporting by writing a custom piece of
|
||||
:ref:`exception middleware <exception-middleware>`. If you do write custom
|
||||
error handling, it's a good idea to emulate Django's built-in error handling
|
||||
and only report/log errors if :setting:`DEBUG` is ``False``.
|
Loading…
Add table
Add a link
Reference in a new issue