Cedric Delacombaz

Cedric Delacombaz

Why do we set `raise_exception=True` in Django Rest Framework GenericAPI views?

Let's say we have following model and we send a request to create an item, but instead of sending an integer as price, we send a string.

# models.py

class Item(models.Model):
    name = models.CharField(max_length=50)
    price = models.IntegerField()

{
  "name": "bread",
  "price": "ten"
}

Response with default behaviour (raise_exception=False)

# views.py

class CreateItemView(GenericAPIView):
    serializer_class = ItemSerializer

    def post(self, request, *args, **kwargs):
        serializer = self.get_serializer(data=request.data)
        serializer.is_valid() # raise_exception=False is the default
        serializer.save()
        return Response(serializer.data)

Django will respond with an internal server error (500) and following error message:

You cannot call .save() on a serializer with invalid data.

What happens, is that the validation fails, but nothing is done with the reported errors. The code execution continues and .save() fails as there is no validated data to use.

Handle errors with default behaviour (raise_exception=False)

We could check what serializer.is_valid() returns and based on that, raise an exception ourselves.

# views.py

class CreateItemView(GenericAPIView):
    serializer_class = ItemSerializer

    def post(self, request, *args, **kwargs):
        serializer = self.get_serializer(data=request.data)
        if not serializer.is_valid(): # raise_exception=False is the default
            raise Exception('something went wrong', serializer.errors)
        serializer.save()
        return Response(serializer.data)

This would return an internal server error (500) and following message:

('something went wrong!', {'price': [ErrorDetail(string='A valid integer is required.', code='invalid')]})

As you can see, DRF already formats the dictionary in a certain way. When used with the ValidationError class from DRF, it actually gives us a nice JSON object which can be used to display error messages on related form fields in the frontend. Also, we don't get an internal server error (500) anymore, but a bad request (400). This means that even with DEBUG=False in settings.py, which should be set in production, we would know what went wrong.

# views.py

class CreateItemView(GenericAPIView):
    serializer_class = ItemSerializer

    def post(self, request, *args, **kwargs):
        serializer = self.get_serializer(data=request.data)
        if not serializer.is_valid(): # raise_exception=False is the default
            raise ValidationError(serializer.errors)
        serializer.save()
        return Response(serializer.data)

{
    "price": [
        "A valid integer is required."
    ]
}

A cleaner way to write it - with raise_exception=True

And finally, we can see why we add raise_exception=True. This is simply a cleaner and more concise way to write previous functionality.

if not serializer.is_valid():
    raise ValidationError(serializer.errors)

# is the same as

serializer.is_valid(raise_exception=True)

# views.py

class CreateItemView(GenericAPIView):
    serializer_class = ItemSerializer

    def post(self, request, *args, **kwargs):
        serializer = self.get_serializer(data=request.data)
        serializer.is_valid(raise_exception=True)
        serializer.save()
        return Response(serializer.data)

Most of the time u will want to use raise_exception=True, unless you need to handle serializer's errors in your code, rather than simply telling the user/api consumer that his input is wrong.

Why is False the default value though? Here the answer from the lead developer of DRF, Tom Christie: https://github.com/encode/django-rest-framework/issues/2098#issuecomment-65071603

← Back to home