How to handle error pages in Django

This article mainly introduces how to handle error pages in Django, that is, the page information returned when an exception occurs. For more information, please refer to the Web application we have written in the next few minutes, then let's make some minor damages. We intentionally introduced a Python error in the views. py file and commented out a row of offset = int (offset) in the hours_ahead view.

def hours_ahead(request, offset):  # try:  #   offset = int(offset)  # except ValueError:  #   raise Http404()  dt = datetime.datetime.now() + datetime.timedelta(hours=offset)  html = "In %s hour(s), it will be %s." % (offset, dt)  return HttpResponse(html)

Start the development server and access/time/plus/3 /. You will see an error page containing a large amount of information. The top TypeError message is: "unsupported type for timedelta hours component: unicode ".

What's going on? Yes, the datetime. timedelta function requires the hours parameter to be an integer, and we have commented out the code to convert offset to an integer. This causes the TypeError exception to pop up in datetime. timedelta.

This example shows the error page of Django. Let's take a moment to look at this error page and find out what information it provides.

The following are some important points worth noting:

• At the top of the page, you can get the key exception information: abnormal data type, abnormal parameters (such as "unsupported type" in this example ") the file in which an exception is thrown, and the wrong row number.
• Below the critical exception information, this page displays the complete Python tracing information for this exception. This is similar to the tracing information you get in the Python command line interpreter, but the latter is more interactive. For each frame in the stack, Django displays the file name, function or method name, row number, and source code of the row.
• Click this line of code (displayed in dark gray). you can see the lines before and after the error line to learn the context.
• Click "Local vars" for any frame in the stack to view a list of all Local variables and their values when the frame fails. This debugging information is quite useful.
• Note the "Switch to copy-and-paste view" text under "Traceback. Click these words to switch back to another view, which makes it easy for you to copy and paste the content. You can use this exception tracing feature when you want to share it with others for technical support (such as in Django's IRC chat room or email list.
• You can press Share this traceback on a public Web site under the notebook to complete the job. Click it to return the tracing information to http://www.dpaste.com/, where you can get a single URL and share it with others.
• The subsequent "Request information" section contains a large amount of information about the Web requests that generate errors: GET and POST, cookie value, and metadata (such as CGI header ). The Complete Reference of the request object is provided in Appendix H.
• Under the Request information, "Settings" lists the specific configuration information used by Django. (We have mentioned ROOT_URLCONF. next we will show you various Django settings. Appendix D covers all available settings .)

Django's error page can display more information in some cases, such as template syntax errors. Let's talk about the Django template system. Now, cancel the annotation of the line offset = int (offset) to make it work again.

I wonder if you are a programmer who uses the print statement carefully placed to help debugging? You can use the Django error page instead of the print statement. Insert an assert False temporarily at any position in your view to trigger the error page. Then, you can see local variables and program statements. Here is an example of using the hours_ahead view:

def hours_ahead(request, offset):  try:    offset = int(offset)  except ValueError:    raise Http404()  dt = datetime.datetime.now() + datetime.timedelta(hours=offset)  assert False  html = "In %s hour(s), it will be %s." % (offset, dt)  return HttpResponse(html)

Finally, it is obvious that many of the information is sensitive. it exposes the internal structure of your Python code and the Django configuration. it is silly to disclose this information on the Internet. Malicious people will try to use it to attack your Web application and do something dirty. Therefore, Django error messages are only displayed in debug mode. We will explain how to disable debug later. Now, you only need to know that the Django server runs in debug mode by default when you enable it. (Sounds familiar? No error is found on the page. as mentioned above, it works normally .)