Django error handlers - Исправление ошибок и поиск оптимальных решений проблем

Writing views¶

A view function, or view for short, is a Python function that takes a
web request and returns a web response. This response can be the HTML contents
of a web page, or a redirect, or a 404 error, or an XML document, or an image .
. . or anything, really. The view itself contains whatever arbitrary logic is
necessary to return that response. This code can live anywhere you want, as long
as it’s on your Python path. There’s no other requirement–no “magic,” so to
speak. For the sake of putting the code somewhere, the convention is to
put views in a file called views.py, placed in your project or
application directory.

A simple view¶

Here’s a view that returns the current date and time, as an HTML document:

from django.http import HttpResponse
import datetime

def current_datetime(request):
    now = datetime.datetime.now()
    html = "<html><body>It is now %s.</body></html>" % now
    return HttpResponse(html)

Let’s step through this code one line at a time:

First, we import the class HttpResponse from the
django.http module, along with Python’s datetime library.
Next, we define a function called current_datetime. This is the view
function. Each view function takes an HttpRequest
object as its first parameter, which is typically named request.

Note that the name of the view function doesn’t matter; it doesn’t have to
be named in a certain way in order for Django to recognize it. We’re
calling it current_datetime here, because that name clearly indicates
what it does.
The view returns an HttpResponse object that
contains the generated response. Each view function is responsible for
returning an HttpResponse object. (There are
exceptions, but we’ll get to those later.)

Django’s Time Zone

Django includes a TIME_ZONE setting that defaults to
America/Chicago. This probably isn’t where you live, so you might want
to change it in your settings file.

Mapping URLs to views¶

So, to recap, this view function returns an HTML page that includes the current
date and time. To display this view at a particular URL, you’ll need to create a
URLconf; see URL dispatcher for instructions.

Returning errors¶

Django provides help for returning HTTP error codes. There are subclasses of
HttpResponse for a number of common HTTP status codes
other than 200 (which means “OK”). You can find the full list of available
subclasses in the request/response
documentation. Return an instance of one of those subclasses instead of a
normal HttpResponse in order to signify an error. For
example:

from django.http import HttpResponse, HttpResponseNotFound

def my_view(request):
    # ...
    if foo:
        return HttpResponseNotFound('<h1>Page not found</h1>')
    else:
        return HttpResponse('<h1>Page was found</h1>')

There isn’t a specialized subclass for every possible HTTP response code,
since many of them aren’t going to be that common. However, as documented in
the HttpResponse documentation, you can also pass the
HTTP status code into the constructor for HttpResponse
to create a return class for any status code you like. For example:

from django.http import HttpResponse

def my_view(request):
    # ...

    # Return a "created" (201) response code.
    return HttpResponse(status=201)

Because 404 errors are by far the most common HTTP error, there’s an easier way
to handle those errors.

The `Http404` exception¶

class django.http.Http404¶

When you return an error such as HttpResponseNotFound,
you’re responsible for defining the HTML of the resulting error page:

return HttpResponseNotFound('<h1>Page not found</h1>')

For convenience, and because it’s a good idea to have a consistent 404 error page
across your site, Django provides an Http404 exception. If you raise
Http404 at any point in a view function, Django will catch it and return the
standard error page for your application, along with an HTTP error code 404.

Example usage:

from django.http import Http404
from django.shortcuts import render
from polls.models import Poll

def detail(request, poll_id):
    try:
        p = Poll.objects.get(pk=poll_id)
    except Poll.DoesNotExist:
        raise Http404("Poll does not exist")
    return render(request, 'polls/detail.html', {'poll': p})

In order to show customized HTML when Django returns a 404, you can create an
HTML template named 404.html and place it in the top level of your
template tree. This template will then be served when DEBUG is set
to False.

When DEBUG is True, you can provide a message to Http404 and
it will appear in the standard 404 debug template. Use these messages for
debugging purposes; they generally aren’t suitable for use in a production 404
template.

Customizing error views¶

The default error views in Django should suffice for most web applications,
but can easily be overridden if you need any custom behavior. Specify the
handlers as seen below in your URLconf (setting them anywhere else will have no
effect).

The page_not_found() view is overridden by
handler404:

handler404 = 'mysite.views.my_custom_page_not_found_view'

The server_error() view is overridden by
handler500:

handler500 = 'mysite.views.my_custom_error_view'

The permission_denied() view is overridden by
handler403:

handler403 = 'mysite.views.my_custom_permission_denied_view'

The bad_request() view is overridden by
handler400:

handler400 = 'mysite.views.my_custom_bad_request_view'

Testing custom error views¶

To test the response of a custom error handler, raise the appropriate exception
in a test view. For example:

from django.core.exceptions import PermissionDenied
from django.http import HttpResponse
from django.test import SimpleTestCase, override_settings
from django.urls import path


def response_error_handler(request, exception=None):
    return HttpResponse('Error handler content', status=403)


def permission_denied_view(request):
    raise PermissionDenied


urlpatterns = [
    path('403/', permission_denied_view),
]

handler403 = response_error_handler


# ROOT_URLCONF must specify the module that contains handler403 = ...
@override_settings(ROOT_URLCONF=__name__)
class CustomErrorHandlerTests(SimpleTestCase):

    def test_handler_renders_template_response(self):
        response = self.client.get('/403/')
        # Make assertions on the response here. For example:
        self.assertContains(response, 'Error handler content', status_code=403)

Async views¶

As well as being synchronous functions, views can also be asynchronous
(“async”) functions, normally defined using Python’s async def syntax.
Django will automatically detect these and run them in an async context.
However, you will need to use an async server based on ASGI to get their
performance benefits.

Here’s an example of an async view:

import datetime
from django.http import HttpResponse

async def current_datetime(request):
    now = datetime.datetime.now()
    html = '<html><body>It is now %s.</body></html>' % now
    return HttpResponse(html)

You can read more about Django’s async support, and how to best use async
views, in Asynchronous support.

Источник

In this article, we will learn Django exception handling in a very brief and concise manner while covering most of the exceptions and error messages in Django.

Why do we need to handle exceptions?

As a developer, you will encounter various errors either while making the web APIs, templates, or while writing any other piece of code.

Dealing with them is a very time taking process but also is an essential task, and hence this critical skill of exceptions and error handling comes into the picture.

What are Exceptions?

Exceptions in coding are those types of events that lead to undesirable events. These are detected by run-time executives(like consoles and terminals) or by Operating Systems.

They need not necessarily stop the whole program but will lead to undesirable outputs.

For e.g :

Let’s say the client wants to see a particular object from the database. But for some reason, that specific object is not present there.

In this case, the server won’t come to a halt, but the client will get an error since the object is not present in the DB, which is undesirable.

The key difference between Exceptions and Errors

Errors are those events due to which the whole system will come to a halt, and the program will not execute.

Nothing can be done with errors; we can only detect and then make appropriate changes such that they don’t happen.

On the other hand, exceptions are something that the developers can deal with without letting the system come to a halt.

Types of Django Exceptions

Exception Handling

There are many kinds of exceptions in Django, out of which five are extremely important and are used most frequently.

Django Exception classes
Django URL Resolver Exceptions
Django Database Exceptions
Django Http Exceptions
Django Transaction Exceptions

We will learn about them in detail.

1) Django Exception classes

ID	Exception	Description
1	AppRegistryNotReady	– It occurs when the Django models are loaded before the Django app itself. – This exception occurs when you are writing your own scripts and not with default Django app files.
2	ObjectDoesNotExist	As the name suggests, occurs when Object does not exist.
3	EmptyResultSet	Occurs when a query returns an empty set
4	FieldDoesNotExist	This occurs when Field doest not exist in a model.
5	MultipleObjectsReturned	This occurs when a query returns more than one result
6	SuspiciousOperation	This happens when the client does something suspicious for security reasons
7	PermissionDenied	Occurs when the user tries to perform a task which he is not allowed to
8	ViewDoesNotExist	Occurs when Views doesnt not exist
9	MiddlewareNotUsed	This occurs when particular middleware is not used in the MIDDLEWARE section of settings.py
10	ImproperlyConfigured	This occurs when somehow, Django is improperly configured. Usually doesn’t happen when working with default Django Files.
11	FieldError	Happens when there is an error in Model field
12	ValidationError	Happens when Data validation fails in forms or model forms.

Django Exception classes

2) Django URL Resolver Exceptions

ID	Exception	Description
1	Resolver404	– Raised by the function resolve(), a part of Django.http.Http404 library. – The exception occurs when path() does not have a valid View to map.
2	NoReverseMatch	This occurs when the user searches a wrong endpoint.

Django URL Resolver Exceptions

3) Django Database Exceptions

ID	Exception	Description
1	DatabaseError	Occurs when DB is not available
2	IntegrityError	– This occurs when DB expects a value for a field but doesn’t get it from the user. – If True, Django will store empty values as NULL in the database. Default is False.
3	DataError	Occurs due to data-related issues

Django Database Exceptions

4) Django Http Exceptions

This we have seen many times. These are the HTTP exceptions that we import from django.http library

ID	Exception	Description
1	UnreadablePostError	Occurs when a user cancels an upload.

Django Http Exceptions

5) Django Transaction Exceptions

ID	Exception	Description
1	TransactionManagementError	This is raised for all the problems that occur due to database transactions

Django Transaction Exceptions

Simple Implementation of Exception Handling in the Django app

We will do a simple DoesNotExist exception handling on an application that shows information about a particular item in the server.

The code is a part of the Web Application itemsapp built in the REST API article.

Itemsapp is a simple REST API application that allows clients to

View a list of items present in the server (GET endpoint: hostwebsite/items)
Add a new item into the DB (POST endpoint: hostwebsite/items)
View a particular item (GET endpoint: hostwebsite/item/<id>)
Edit a particular item (PUT endpoint: hostwebsite/item/<id>)
Delete a particular item (DELETE endpoint: hostwebsite/item/<id>)

To learn how to make the complete web application, do checkout Rest API article.

Now we will create a webpage that shows the information about a particular item from the DB

Create a ItemModel in models.py to store information about items:

from django.db import models

# Create your models here.

class ItemsModel(models.Model):
    id = models.IntegerField(primary_key = True)
    name = models.CharField(max_length = 80)
    price = models.IntegerField()

    class Meta:
        ordering = ['name']

    def __str__(self):
        return f"{self.name}:{self.price}"

As shown above, the URL path in urls.py will be:

path('/item/<int:nm>',Item)

Now just add a few items into the DB through the admin site.

Admin

Now in views.py, the code to show a particular item with an id = nm will be:

def Item(request,nm):
        item = ItemModel.objects.get(id = nm)
        return HttpResponse(item)

Run the server and check for an object not present in DB, say id = 4

You will get an error message

DoesNotExist

Now we will use Django Exception Handling to handle this error. Edit the code in views.py as follows:

def Item(request,nm):
        try:
            item = ItemsModel.objects.get(id = nm)
        except ItemsModel.DoesNotExist:
            return HttpResponse('Exception: Data Not Found')
        return HttpResponse(item)

Notice the line “except ItemsModel.DoesNotExist“. This is where Python automatically captures the exception. You can replace the exception with one of the exceptions from the list above, and handle the same with a custom error message.

For that first import

from django.core.exceptions import *

That’s it, now we can go on and add exception we want

def Item(request,nm):
        try:
            item = ItemsModel.objects.get(id = nm)
        except ObjectDoesNotExist:
            print('Data Not Found')
        return HttpResponse(item)

Now run the server and search for id = 4

Exception Handling

Similarly, we will handle other important and most used exceptions from the django.core.exceptions

Some other important Exceptions

First we will have to import the library

from django.core.exceptions import <error_name>

Lets go through the important exceptions

Field Dos Not Exist

This happens when the model field does not exist

try:
    Model.objects.get(<field> = '<value>')
except FieldDoesNotExist:
    print('The Field is missing')

Multiple Objects Returned

Happens when more than one object in DB has same value for a certain field

try:
    Model.objects.get(<name> = '<value>')
except MultipleObjectsReturned:
    print('More than one object with the same name are present in the Database')

View Does Not Exist

Happens when we call a view through path() in urls.py , but the view does not exist.

try:
    path('item/', <View>)
except ViewDoesNotExist:
    print('The View does not exist in views.py')

Validation Error

Happens when certain information in the form data is not valid

data = form.cleaned_data['name']
if '<field_name>' not in data:
    raise ValidationError('This name does not exist')

Conclusion

That’s it, fellas! I do hope that this article helped increase your knowledge and understanding of Django exceptions. Do refer to the official documentation for more information.

Stay safe !! keep Learning !!

Источник

Following the tutorial found here exactly, I cannot create a custom 500 or 404 error page. If I do type in a bad url, the page gives me the default error page. Is there anything I should be checking for that would prevent a custom page from showing up?

File directories:

mysite/
    mysite/
        __init__.py
        __init__.pyc
        settings.py
        settings.pyc
        urls.py
        urls.pyc
        wsgi.py
        wsgi.pyc
    polls/
        templates/
            admin/
                base_site.html
            404.html
            500.html
            polls/
                detail.html
                index.html
        __init__.py
        __init__.pyc
        admin.py
        admin.pyc
        models.py
        models.pyc
        tests.py
        urls.py
        urls.pyc
        view.py
        views.pyc
    templates/
    manage.py

within mysite/settings.py I have these enabled:

DEBUG = False
TEMPLATE_DEBUG = DEBUG

#....

TEMPLATE_DIRS = (
    'C:/Users/Me/Django/mysite/templates', 
)

within mysite/polls/urls.py:

from django.conf.urls import patterns, url

from polls import views

urlpatterns = patterns('',
    url(r'^$', views.index, name='index'),
    url(r'^(?P<poll_id>d+)/$', views.detail, name='detail'),
    url(r'^(?P<poll_id>d+)/results/$', views.results, name='results'),
    url(r'^(?P<poll_id>d+)/vote/$', views.vote, name='vote'),
)

I can post any other code necessary, but what should I be changing to get a custom 500 error page if I use a bad url?

vvvvv

21.1k17 gold badges46 silver badges66 bronze badges

asked Jul 15, 2013 at 20:07

Under your main views.py add your own custom implementation of the following two views, and just set up the templates 404.html and 500.html with what you want to display.

With this solution, no custom code needs to be added to urls.py

Here’s the code:

from django.shortcuts import render_to_response
from django.template import RequestContext


def handler404(request, *args, **argv):
    response = render_to_response('404.html', {},
                                  context_instance=RequestContext(request))
    response.status_code = 404
    return response


def handler500(request, *args, **argv):
    response = render_to_response('500.html', {},
                                  context_instance=RequestContext(request))
    response.status_code = 500
    return response

Update

handler404 and handler500 are exported Django string configuration variables found in django/conf/urls/__init__.py. That is why the above config works.

To get the above config to work, you should define the following variables in your urls.py file and point the exported Django variables to the string Python path of where these Django functional views are defined, like so:

# project/urls.py

handler404 = 'my_app.views.handler404'
handler500 = 'my_app.views.handler500'

Update for Django 2.0

Signatures for handler views were changed in Django 2.0:
https://docs.djangoproject.com/en/2.0/ref/views/#error-views

If you use views as above, handler404 will fail with message:

«handler404() got an unexpected keyword argument ‘exception'»

In such case modify your views like this:

def handler404(request, exception, template_name="404.html"):
    response = render_to_response(template_name)
    response.status_code = 404
    return response

answered Jul 13, 2014 at 16:56

Aaron LelevierAaron Lelevier

19.3k11 gold badges75 silver badges110 bronze badges

Official answer:

Here is the link to the official documentation on how to set up custom error views:

https://docs.djangoproject.com/en/stable/topics/http/views/#customizing-error-views

It says to add lines like these in your URLconf (setting them anywhere else will have no effect):

handler404 = 'mysite.views.my_custom_page_not_found_view'
handler500 = 'mysite.views.my_custom_error_view'
handler403 = 'mysite.views.my_custom_permission_denied_view'
handler400 = 'mysite.views.my_custom_bad_request_view'

You can also customise the CSRF error view by modifying the setting CSRF_FAILURE_VIEW.

Default error handlers:

It’s worth reading the documentation of the default error handlers, page_not_found, server_error, permission_denied and bad_request. By default, they use these templates if they can find them, respectively: 404.html, 500.html, 403.html, and 400.html.

So if all you want to do is make pretty error pages, just create those files in a TEMPLATE_DIRS directory, you don’t need to edit URLConf at all. Read the documentation to see which context variables are available.

In Django 1.10 and later, the default CSRF error view uses the template 403_csrf.html.

Gotcha:

Don’t forget that DEBUG must be set to False for these to work, otherwise, the normal debug handlers will be used.

answered Jun 3, 2016 at 9:52

FlimmFlimm

129k44 gold badges244 silver badges254 bronze badges

Add these lines in urls.py

urls.py

from django.conf.urls import (
handler400, handler403, handler404, handler500
)

handler400 = 'my_app.views.bad_request'
handler403 = 'my_app.views.permission_denied'
handler404 = 'my_app.views.page_not_found'
handler500 = 'my_app.views.server_error'

# ...

and implement our custom views in views.py.

views.py

from django.shortcuts import (
render_to_response
)
from django.template import RequestContext

# HTTP Error 400
def bad_request(request):
    response = render_to_response(
        '400.html',
        context_instance=RequestContext(request)
        )

        response.status_code = 400

        return response

# ...

answered Oct 26, 2015 at 10:03

ArmanceArmance

5,30014 gold badges56 silver badges79 bronze badges

Django 3.0+ 4.0+

here is link how to customize error views

here is link how to render a view

in the urls.py (the main one, in project folder), put:

handler404 = 'my_app_name.views.custom_page_not_found_view'
handler500 = 'my_app_name.views.custom_error_view'
handler403 = 'my_app_name.views.custom_permission_denied_view'
handler400 = 'my_app_name.views.custom_bad_request_view'

and in the mentioned app (my_app_name) put in the views.py:

def custom_page_not_found_view(request, exception):
    return render(request, "errors/404.html", {})

def custom_error_view(request, exception=None):
    return render(request, "errors/500.html", {})

def custom_permission_denied_view(request, exception=None):
    return render(request, "errors/403.html", {})

def custom_bad_request_view(request, exception=None):
    return render(request, "errors/400.html", {})

NOTE: errors/404.html is the path if you place your files into the projects (not the apps) template foldertemplates/errors/404.html so please place the files where you want and write the right path.

NOTE 2: After page reload, if you still see the old template, change in settings.py DEBUG=True, save it, and then again to False and save again (that will restart the server and collect the new files).

answered Mar 31, 2020 at 20:00

elano7elano7

1,1561 gold badge15 silver badges16 bronze badges

From the page you referenced:

When you raise Http404 from within a view, Django will load a special view devoted to handling 404 errors. It finds it by looking for the variable handler404 in your root URLconf (and only in your root URLconf; setting handler404 anywhere else will have no effect), which is a string in Python dotted syntax – the same format the normal URLconf callbacks use. A 404 view itself has nothing special: It’s just a normal view.

So I believe you need to add something like this to your urls.py:

handler404 = 'views.my_404_view'

and similar for handler500.

answered Jul 15, 2013 at 20:13

Mike PelleyMike Pelley

2,90121 silver badges23 bronze badges

If all you need is to show custom pages which have some fancy error messages for your site when DEBUG = False, then add two templates named 404.html and 500.html in your templates directory and it will automatically pick up this custom pages when a 404 or 500 is raised.

answered Dec 1, 2016 at 4:54

In Django 3.x, the accepted answer won’t work because render_to_response has been removed completely as well as some more changes have been made since the version the accepted answer worked for.

Some other answers are also there but I’m presenting a little cleaner answer:

In your main urls.py file:

handler404 = 'yourapp.views.handler404'
handler500 = 'yourapp.views.handler500'

In yourapp/views.py file:

def handler404(request, exception):
    context = {}
    response = render(request, "pages/errors/404.html", context=context)
    response.status_code = 404
    return response


def handler500(request):
    context = {}
    response = render(request, "pages/errors/500.html", context=context)
    response.status_code = 500
    return response

Ensure that you have imported render() in yourapp/views.py file:

from django.shortcuts import render

Side note: render_to_response() was deprecated in Django 2.x and it has been completely removed in verision 3.x.

answered Feb 20, 2020 at 11:19

RehmatRehmat

4,5613 gold badges21 silver badges38 bronze badges

No additional view is required. https://docs.djangoproject.com/en/3.0/ref/views/

Just put the error files in the root of templates directory

404.html
400.html
403.html
500.html

And it should use your error page when debug is False

answered May 19, 2020 at 13:10

Anuj TBEAnuj TBE

8,72023 gold badges127 silver badges269 bronze badges

settings.py:

DEBUG = False
TEMPLATE_DEBUG = DEBUG
ALLOWED_HOSTS = ['localhost']  #provide your host name

and just add your 404.html and 500.html pages in templates folder.
remove 404.html and 500.html from templates in polls app.

Paolo

19.3k21 gold badges75 silver badges113 bronze badges

answered Mar 3, 2016 at 10:58

Rakesh babuRakesh babu

3156 silver badges11 bronze badges

In Django 2.* you can use this construction in views.py

def handler404(request, exception):
    return render(request, 'errors/404.html', locals())

In settings.py

DEBUG = False

if DEBUG is False:
    ALLOWED_HOSTS = [
        '127.0.0.1:8000',
        '*',
    ]

if DEBUG is True:
    ALLOWED_HOSTS = []

In urls.py

# https://docs.djangoproject.com/en/2.0/topics/http/views/#customizing-error-views
handler404 = 'YOUR_APP_NAME.views.handler404'

Usually i creating default_app and handle site-wide errors, context processors in it.

answered Feb 26, 2018 at 8:38

DenisDenis

6591 gold badge9 silver badges21 bronze badges

Make an error, on the error page find out from where django is loading templates. I mean the path stack. In base template_dir add these html pages 500.html , 404.html. When these errors occur the respective template files will be automatically loaded.

You can add pages for other error codes too, like 400 and 403.

vvvvv

21.1k17 gold badges46 silver badges66 bronze badges

answered Aug 17, 2016 at 9:42

ALLSYEDALLSYED

1,46317 silver badges15 bronze badges

As one single line (for 404 generic page):

from django.shortcuts import render_to_response
from django.template import RequestContext

return render_to_response('error/404.html', {'exception': ex},
                                      context_instance=RequestContext(request), status=404)

Francois

5054 silver badges14 bronze badges

answered May 4, 2015 at 13:07

FireZenkFireZenk

9961 gold badge17 silver badges28 bronze badges

# views.py
def handler404(request, exception):
    context = RequestContext(request)
    err_code = 404
    response = render_to_response('404.html', {"code":err_code}, context)
    response.status_code = 404
    return response

# <project_folder>.urls.py
handler404 = 'todo.views.handler404'

This works on django 2.0

Be sure to include your custom 404.html inside the app templates folder.

ayhan

68.1k18 gold badges177 silver badges195 bronze badges

answered Jun 30, 2018 at 7:58

ENDEESAENDEESA

2,9682 gold badges19 silver badges17 bronze badges

Try moving your error templates to .../Django/mysite/templates/.

I am note sure about this one, but I think these need to be «global» to the website.

vvvvv

21.1k17 gold badges46 silver badges66 bronze badges

answered Jul 15, 2013 at 20:16

astrognocciastrognocci

1,0577 silver badges16 bronze badges

In Django root urls.py file, add the below lines

from django.conf.urls import (handler400, handler403, handler404, handler500)

handler400 = 'app.views.bad_request'
handler403 = 'app.views.permission_denied'
handler404 = 'app.views.page_not_found'
handler500 = 'app.views.server_error'

In your app’s views.py file, create the respective functions.

def server_error(request, exception=None):
    # return render(request, '500.html')
    return redirect('/')

Finally, in your settings.py file, set DEBUG = False

answered Jan 28, 2022 at 7:12

I had an additional

TEMPLATE_DIRS

within my settings.py and that was causing the problem.

_{This answer was posted as an edit to the question Django, creating a custom 500/404 error page by the OP reZach under CC BY-SA 3.0.}

answered Dec 22, 2022 at 9:44

vvvvvvvvvv

21.1k17 gold badges46 silver badges66 bronze badges

In urls.py, enter this code:

from django.conf.urls import (handler400, handler403, handler404, handler500)

handler404 = 'my_app.views.page_not_found_view'

then add this code in your views.py

from django.shortcuts import render,get_object_or_404
def page_not_found_view(request, exception):
    return render(request, '404.html', status=404)

Dont forget to set DEBUG = False and also set ALLOWED_HOSTS = [127.0.0.1] while you are testing in your laptop.

vvvvv

21.1k17 gold badges46 silver badges66 bronze badges

answered May 23, 2022 at 8:40

MajidMajid

13 bronze badges

You don’t need to do anything fancy, just create a 404.html file in your templates. Go to settings.py and set:

DEBUG = False
ALLOWED_HOSTS = ["*"]

It will automatically overwrite the default.

vvvvv

21.1k17 gold badges46 silver badges66 bronze badges

answered Dec 14, 2022 at 1:57

Django > 2.2

from django.shortcuts import render_to_response, render
from django.template import RequestContext
def handler500(request, *args, **argv):
    context = {}
    print(request.body, '==========')
    response = render(request, '500.jinja', context=context)
    response.status_code = 500
    return response

in urls.py

handler500 = 'apps.core.views.handler500'

answered Dec 30, 2022 at 14:58

Источник

source
exceptions.py

Exceptions… allow error handling to be organized cleanly in a central or high-level place within the program structure.

— Doug Hellmann, Python Exception Handling Techniques

Exception handling in REST framework views

REST framework’s views handle various exceptions, and deal with returning appropriate error responses.

The handled exceptions are:

Subclasses of APIException raised inside REST framework.
Django’s Http404 exception.
Django’s PermissionDenied exception.

In each case, REST framework will return a response with an appropriate status code and content-type. The body of the response will include any additional details regarding the nature of the error.

Most error responses will include a key detail in the body of the response.

For example, the following request:

DELETE http://api.example.com/foo/bar HTTP/1.1
Accept: application/json

Might receive an error response indicating that the DELETE method is not allowed on that resource:

HTTP/1.1 405 Method Not Allowed
Content-Type: application/json
Content-Length: 42

{"detail": "Method 'DELETE' not allowed."}

Validation errors are handled slightly differently, and will include the field names as the keys in the response. If the validation error was not specific to a particular field then it will use the «non_field_errors» key, or whatever string value has been set for the NON_FIELD_ERRORS_KEY setting.

An example validation error might look like this:

HTTP/1.1 400 Bad Request
Content-Type: application/json
Content-Length: 94

{"amount": ["A valid integer is required."], "description": ["This field may not be blank."]}

Custom exception handling

You can implement custom exception handling by creating a handler function that converts exceptions raised in your API views into response objects. This allows you to control the style of error responses used by your API.

The function must take a pair of arguments, the first is the exception to be handled, and the second is a dictionary containing any extra context such as the view currently being handled. The exception handler function should either return a Response object, or return None if the exception cannot be handled. If the handler returns None then the exception will be re-raised and Django will return a standard HTTP 500 ‘server error’ response.

For example, you might want to ensure that all error responses include the HTTP status code in the body of the response, like so:

HTTP/1.1 405 Method Not Allowed
Content-Type: application/json
Content-Length: 62

{"status_code": 405, "detail": "Method 'DELETE' not allowed."}

In order to alter the style of the response, you could write the following custom exception handler:

from rest_framework.views import exception_handler

def custom_exception_handler(exc, context):
    # Call REST framework's default exception handler first,
    # to get the standard error response.
    response = exception_handler(exc, context)

    # Now add the HTTP status code to the response.
    if response is not None:
        response.data['status_code'] = response.status_code

    return response

The context argument is not used by the default handler, but can be useful if the exception handler needs further information such as the view currently being handled, which can be accessed as context['view'].

The exception handler must also be configured in your settings, using the EXCEPTION_HANDLER setting key. For example:

REST_FRAMEWORK = {
    'EXCEPTION_HANDLER': 'my_project.my_app.utils.custom_exception_handler'
}

If not specified, the 'EXCEPTION_HANDLER' setting defaults to the standard exception handler provided by REST framework:

REST_FRAMEWORK = {
    'EXCEPTION_HANDLER': 'rest_framework.views.exception_handler'
}

Note that the exception handler will only be called for responses generated by raised exceptions. It will not be used for any responses returned directly by the view, such as the HTTP_400_BAD_REQUEST responses that are returned by the generic views when serializer validation fails.

API Reference

APIException

Signature: APIException()

The base class for all exceptions raised inside an APIView class or @api_view.

To provide a custom exception, subclass APIException and set the .status_code, .default_detail, and default_code attributes on the class.

For example, if your API relies on a third party service that may sometimes be unreachable, you might want to implement an exception for the «503 Service Unavailable» HTTP response code. You could do this like so:

from rest_framework.exceptions import APIException

class ServiceUnavailable(APIException):
    status_code = 503
    default_detail = 'Service temporarily unavailable, try again later.'
    default_code = 'service_unavailable'

Inspecting API exceptions

There are a number of different properties available for inspecting the status
of an API exception. You can use these to build custom exception handling
for your project.

The available attributes and methods are:

.detail — Return the textual description of the error.
.get_codes() — Return the code identifier of the error.
.get_full_details() — Return both the textual description and the code identifier.

In most cases the error detail will be a simple item:

>>> print(exc.detail)
You do not have permission to perform this action.
>>> print(exc.get_codes())
permission_denied
>>> print(exc.get_full_details())
{'message':'You do not have permission to perform this action.','code':'permission_denied'}

In the case of validation errors the error detail will be either a list or
dictionary of items:

>>> print(exc.detail)
{"name":"This field is required.","age":"A valid integer is required."}
>>> print(exc.get_codes())
{"name":"required","age":"invalid"}
>>> print(exc.get_full_details())
{"name":{"message":"This field is required.","code":"required"},"age":{"message":"A valid integer is required.","code":"invalid"}}

ParseError

Signature: ParseError(detail=None, code=None)

Raised if the request contains malformed data when accessing request.data.

By default this exception results in a response with the HTTP status code «400 Bad Request».

AuthenticationFailed

Signature: AuthenticationFailed(detail=None, code=None)

Raised when an incoming request includes incorrect authentication.

By default this exception results in a response with the HTTP status code «401 Unauthenticated», but it may also result in a «403 Forbidden» response, depending on the authentication scheme in use. See the authentication documentation for more details.

NotAuthenticated

Signature: NotAuthenticated(detail=None, code=None)

Raised when an unauthenticated request fails the permission checks.

PermissionDenied

Signature: PermissionDenied(detail=None, code=None)

Raised when an authenticated request fails the permission checks.

By default this exception results in a response with the HTTP status code «403 Forbidden».

NotFound

Signature: NotFound(detail=None, code=None)

Raised when a resource does not exists at the given URL. This exception is equivalent to the standard Http404 Django exception.

By default this exception results in a response with the HTTP status code «404 Not Found».

MethodNotAllowed

Signature: MethodNotAllowed(method, detail=None, code=None)

Raised when an incoming request occurs that does not map to a handler method on the view.

By default this exception results in a response with the HTTP status code «405 Method Not Allowed».

NotAcceptable

Signature: NotAcceptable(detail=None, code=None)

Raised when an incoming request occurs with an Accept header that cannot be satisfied by any of the available renderers.

By default this exception results in a response with the HTTP status code «406 Not Acceptable».

UnsupportedMediaType

Signature: UnsupportedMediaType(media_type, detail=None, code=None)

Raised if there are no parsers that can handle the content type of the request data when accessing request.data.

By default this exception results in a response with the HTTP status code «415 Unsupported Media Type».

Throttled

Signature: Throttled(wait=None, detail=None, code=None)

Raised when an incoming request fails the throttling checks.

By default this exception results in a response with the HTTP status code «429 Too Many Requests».

ValidationError

Signature: ValidationError(detail=None, code=None)

The ValidationError exception is slightly different from the other APIException classes:

The detail argument may be a list or dictionary of error details, and may also be a nested data structure. By using a dictionary, you can specify field-level errors while performing object-level validation in the validate() method of a serializer. For example. raise serializers.ValidationError({'name': 'Please enter a valid name.'})
By convention you should import the serializers module and use a fully qualified ValidationError style, in order to differentiate it from Django’s built-in validation error. For example. raise serializers.ValidationError('This field must be an integer value.')

The ValidationError class should be used for serializer and field validation, and by validator classes. It is also raised when calling serializer.is_valid with the raise_exception keyword argument:

serializer.is_valid(raise_exception=True)

The generic views use the raise_exception=True flag, which means that you can override the style of validation error responses globally in your API. To do so, use a custom exception handler, as described above.

By default this exception results in a response with the HTTP status code «400 Bad Request».

Generic Error Views

Django REST Framework provides two error views suitable for providing generic JSON 500 Server Error and
400 Bad Request responses. (Django’s default error views provide HTML responses, which may not be appropriate for an
API-only application.)

Use these as per Django’s Customizing error views documentation.

`rest_framework.exceptions.server_error`

Returns a response with status code 500 and application/json content type.

Set as handler500:

handler500 = 'rest_framework.exceptions.server_error'

`rest_framework.exceptions.bad_request`

Returns a response with status code 400 and application/json content type.

Set as handler400:

handler400 = 'rest_framework.exceptions.bad_request'

Third party packages

The following third-party packages are also available.

DRF Standardized Errors

The drf-standardized-errors package provides an exception handler that generates the same format for all 4xx and 5xx responses. It is a drop-in replacement for the default exception handler and allows customizing the error response format without rewriting the whole exception handler. The standardized error response format is easier to document and easier to handle by API consumers.

Источник

exceptions.py

Exceptions… allow error handling to be organized cleanly in a central or high-level place within the program structure.

— Doug Hellmann, Python Exception Handling Techniques

Exception handling in REST framework views

REST framework’s views handle various exceptions, and deal with returning appropriate error responses.

The handled exceptions are:

Subclasses of APIException raised inside REST framework.
Django’s Http404 exception.
Django’s PermissionDenied exception.

In each case, REST framework will return a response with an appropriate status code and content-type. The body of the response will include any additional details regarding the nature of the error.

Most error responses will include a key detail in the body of the response.

For example, the following request:

DELETE http://api.example.com/foo/bar HTTP/1.1
Accept: application/json

Might receive an error response indicating that the DELETE method is not allowed on that resource:

HTTP/1.1 405 Method Not Allowed
Content-Type: application/json
Content-Length: 42

{"detail": "Method 'DELETE' not allowed."}

An example validation error might look like this:

HTTP/1.1 400 Bad Request
Content-Type: application/json
Content-Length: 94

{"amount": ["A valid integer is required."], "description": ["This field may not be blank."]}

Custom exception handling

For example, you might want to ensure that all error responses include the HTTP status code in the body of the response, like so:

HTTP/1.1 405 Method Not Allowed
Content-Type: application/json
Content-Length: 62

{"status_code": 405, "detail": "Method 'DELETE' not allowed."}

In order to alter the style of the response, you could write the following custom exception handler:

from rest_framework.views import exception_handler

def custom_exception_handler(exc, context):
    # Call REST framework's default exception handler first,
    # to get the standard error response.
    response = exception_handler(exc, context)

    # Now add the HTTP status code to the response.
    if response is not None:
        response.data['status_code'] = response.status_code

    return response

The exception handler must also be configured in your settings, using the EXCEPTION_HANDLER setting key. For example:

REST_FRAMEWORK = {
    'EXCEPTION_HANDLER': 'my_project.my_app.utils.custom_exception_handler'
}

If not specified, the 'EXCEPTION_HANDLER' setting defaults to the standard exception handler provided by REST framework:

REST_FRAMEWORK = {
    'EXCEPTION_HANDLER': 'rest_framework.views.exception_handler'
}

API Reference

APIException

Signature: APIException()

The base class for all exceptions raised inside an APIView class or @api_view.

To provide a custom exception, subclass APIException and set the .status_code, .default_detail, and default_code attributes on the class.

from rest_framework.exceptions import APIException

class ServiceUnavailable(APIException):
    status_code = 503
    default_detail = 'Service temporarily unavailable, try again later.'
    default_code = 'service_unavailable'

Inspecting API exceptions

There are a number of different properties available for inspecting the status
of an API exception. You can use these to build custom exception handling
for your project.

The available attributes and methods are:

.detail — Return the textual description of the error.
.get_codes() — Return the code identifier of the error.
.get_full_details() — Return both the textual description and the code identifier.

In most cases the error detail will be a simple item:

>>> print(exc.detail)
You do not have permission to perform this action.
>>> print(exc.get_codes())
permission_denied
>>> print(exc.get_full_details())
{'message':'You do not have permission to perform this action.','code':'permission_denied'}

In the case of validation errors the error detail will be either a list or
dictionary of items:

>>> print(exc.detail)
{"name":"This field is required.","age":"A valid integer is required."}
>>> print(exc.get_codes())
{"name":"required","age":"invalid"}
>>> print(exc.get_full_details())
{"name":{"message":"This field is required.","code":"required"},"age":{"message":"A valid integer is required.","code":"invalid"}}

ParseError

Signature: ParseError(detail=None, code=None)

Raised if the request contains malformed data when accessing request.data.

By default this exception results in a response with the HTTP status code «400 Bad Request».

AuthenticationFailed

Signature: AuthenticationFailed(detail=None, code=None)

Raised when an incoming request includes incorrect authentication.

NotAuthenticated

Signature: NotAuthenticated(detail=None, code=None)

Raised when an unauthenticated request fails the permission checks.

PermissionDenied

Signature: PermissionDenied(detail=None, code=None)

Raised when an authenticated request fails the permission checks.

By default this exception results in a response with the HTTP status code «403 Forbidden».

NotFound

Signature: NotFound(detail=None, code=None)

Raised when a resource does not exists at the given URL. This exception is equivalent to the standard Http404 Django exception.

By default this exception results in a response with the HTTP status code «404 Not Found».

MethodNotAllowed

Signature: MethodNotAllowed(method, detail=None, code=None)

Raised when an incoming request occurs that does not map to a handler method on the view.

By default this exception results in a response with the HTTP status code «405 Method Not Allowed».

NotAcceptable

Signature: NotAcceptable(detail=None, code=None)

Raised when an incoming request occurs with an Accept header that cannot be satisfied by any of the available renderers.

By default this exception results in a response with the HTTP status code «406 Not Acceptable».

Signature: UnsupportedMediaType(media_type, detail=None, code=None)

Raised if there are no parsers that can handle the content type of the request data when accessing request.data.

By default this exception results in a response with the HTTP status code «415 Unsupported Media Type».

Throttled

Signature: Throttled(wait=None, detail=None, code=None)

Raised when an incoming request fails the throttling checks.

By default this exception results in a response with the HTTP status code «429 Too Many Requests».

ValidationError

Signature: ValidationError(detail, code=None)

The ValidationError exception is slightly different from the other APIException classes:

The detail argument is mandatory, not optional.
The detail argument may be a list or dictionary of error details, and may also be a nested data structure. By using a dictionary, you can specify field-level errors while performing object-level validation in the validate() method of a serializer. For example. raise serializers.ValidationError({'name': 'Please enter a valid name.'})
By convention you should import the serializers module and use a fully qualified ValidationError style, in order to differentiate it from Django’s built-in validation error. For example. raise serializers.ValidationError('This field must be an integer value.')

serializer.is_valid(raise_exception=True)

By default this exception results in a response with the HTTP status code «400 Bad Request».

Generic Error Views

Use these as per Django’s Customizing error views documentation.

`rest_framework.exceptions.server_error`

Returns a response with status code 500 and application/json content type.

Set as handler500:

handler500 = 'rest_framework.exceptions.server_error'

`rest_framework.exceptions.bad_request`

Returns a response with status code 400 and application/json content type.

Set as handler400:

handler400 = 'rest_framework.exceptions.bad_request'

Third party packages

The following third-party packages are also available.

DRF Standardized Errors

Источник

1. Кастомизация ошибок 404, 500
2. Кастомизация ошибки 403

Многие ресурсы имеют оформленные страницы ошибок, если происходит сбой в обработке запроса от клиента.

Для начала на сайте была сделана кастомизация наиболее часто возникающих ошибок, другие при отладке пока не попадались, но всё впереди.

Как объявлено в заголовке статьи, кастомизированы был следующие ошибки:

403 — Ошибка авторизации, доступ запрещён.
404 — Страница не найдена;
500 — Внутренняя ошибка сервера;

Кастомизация ошибок 404, 500

Для кастомизации ошибок 404 и 500 необходимо написать обработчики запросов, и достаточно написать их представления в виде метода.

В шаблоны добавляем свои кастомизированные html файлы, то есть:

error404.html
error500.html

Модуль, в котором реализованы представления для данного сайта — это

home.

В шаблонах этого же модуля помещены сами шаблоны кастомизированных ошибок.

В файле

urls.py

главного модуля сайта переопределяем обработчики по умолчанию:

handler404
handler500

В коде это выглядит так:

from home.views import e_handler404, e_handler500

handler404 = e_handler404
handler500 = e_handler500


  Опишем представления в файле

  

   views.py

  

  модуля

  

   home:

  
from django.shortcuts import render_to_response
from django.template import RequestContext


def e_handler404(request):
    context = RequestContext(request)
    response = render_to_response('error404.html', context)
    response.status_code = 404
    return response


def e_handler500(request):
    context = RequestContext(request)
    response = render_to_response('error500.html', context)
    response.status_code = 500
    return response


  Кастомизация ошибки 403

 

  Ошибка 403 возникает в том случае, когда не авторизованный пользователь пытается получить доступ к той части сайта, в которую доступ разрешён только авторизованным пользователям.
 

  В Django это достигается за счёт проверки статуса пользователя и добавления на страницы защитного токена, механизм

  

   CSRF.

  

  Данная ошибка может возникнуть и в том случае, если пользователь авторизован, но совершает действия, при которых требуется проверка токена CSRF, а сам токен был потерян или не верен. Дело в том, что для корректности работы токена, необходимо добавлять в шаблоне в формах специальный тег:
 
{% csrf_token %}


  В него и будет подставляться токен, но просто добавить в шаблон, его не достаточно. Прежде, чем начать рендер шаблон, необходимо добавить токен в контекст, который будет передан в шаблон. То есть,
 
from django.template.context_processors import csrf
from django.shortcuts import render_to_response


def any_request(request):
    context = {}
    context.update(csrf(request))

    ...
    return render_to_response('any_request.html', context=context)


  Ну а теперь ближе к непосредственно кастомизации. Для работы csrf необходимо, чтобы в файле

  

   settings.py

  

  добавлен модуль csrf и указано представление, которое будет заниматься обработкой данной ошибки:
 
MIDDLEWARE = [
    ...
    'django.middleware.csrf.CsrfViewMiddleware',
    ...
]

CSRF_FAILURE_VIEW = 'home.views.csrf_failure'


  В шаблонах добавим

  

   error403.html,

  

  а в файле

  

   views.py

  

  пропишем обработчик представления.
 
def csrf_failure(request, reason=""):
    context = RequestContext(request)
    response = render_to_response('error403.html', context)
    response.status_code = 403
    return response


  Для

  

   Django

  

  рекомендую
   VDS-сервера хостера Timeweb
  .

Источник

Writing views¶

A simple view¶

Mapping URLs to views¶

Returning errors¶

The Http404 exception¶

Customizing error views¶

Testing custom error views¶

Async views¶

Why do we need to handle exceptions?

What are Exceptions?

The key difference between Exceptions and Errors

Types of Django Exceptions

1) Django Exception classes

2) Django URL Resolver Exceptions

3) Django Database Exceptions

4) Django Http Exceptions

5) Django Transaction Exceptions

Simple Implementation of Exception Handling in the Django app

Some other important Exceptions

Field Dos Not Exist

Multiple Objects Returned

View Does Not Exist

Validation Error

Conclusion

Official answer:

Default error handlers:

Gotcha:

urls.py

views.py

Exception handling in REST framework views

Custom exception handling

API Reference

APIException

Inspecting API exceptions

ParseError

AuthenticationFailed

NotAuthenticated

PermissionDenied

NotFound

MethodNotAllowed

NotAcceptable

UnsupportedMediaType

Throttled

ValidationError

Generic Error Views

rest_framework.exceptions.server_error

rest_framework.exceptions.bad_request

Third party packages

DRF Standardized Errors

Exception handling in REST framework views

Custom exception handling

API Reference

APIException

Inspecting API exceptions

ParseError

AuthenticationFailed

NotAuthenticated

PermissionDenied

NotFound

MethodNotAllowed

NotAcceptable

Throttled

ValidationError

Generic Error Views

rest_framework.exceptions.server_error

rest_framework.exceptions.bad_request

Third party packages

DRF Standardized Errors

Кастомизация ошибок 404, 500

Кастомизация ошибки 403

The `Http404` exception¶

`rest_framework.exceptions.server_error`

`rest_framework.exceptions.bad_request`

`rest_framework.exceptions.server_error`

`rest_framework.exceptions.bad_request`