Django Exceptions & Error-handling

Django Exceptions & Error-handling

What are Exceptions?

Exceptions are those events in a program occurring of which can lead to undesirable behavior. They are detectable by run time executive or Operating System. Exceptions do not always emerge from errors.

Errors, on the other hand, are complete halt. If an error occurs, your program will not execute. When the errors like OutOfMemory occurs, your program literally has no memory to execute. Thus, the execution stops.

The programmers can do nothing about errors. Errors can only be caught and an appropriate response can be generated, that’s all can be done.

Exceptions are the ones in which we developers actually deal with.

We all are familiar with web errors, the most popular being 404 FileNotFound Error.

Django Exceptions

There are multiple packages for developer’s use. These packages may/ may not come in your use-case. For the matter, the 1st package we are going to discuss is for those developers who are writing their own Python scripts. These developers customize the Django at a low level.

1. django.core.exceptions Package

   This package provides us with low-level exceptions. It enables us to define new rules for our Django project. We can load models, views in our own defined ways.

This module has use-cases like:

• When you are working on a custom middleware.
• When making some changes to Django ORM.

For that, we will have to understand some very basic concepts.

1.1. AppRegistryNotReady

This error occurs when the application model is imported before the app-loading process.

When we start our Django server, it first looks for settings.py file.

Django then installs all the applications in the list INSTALLED_APPS. Here, is a part of that process.

App registry in brief:

When Django project starts, it generates an application registry. It contains the information in settings.py and some more custom settings. This registry will keep record and install all the important components.

This registry contains settings-config of all apps inside INSTALLED_APPS. It is the first kernel of your Django project. To use any app or submodule in your project, it has to load-in here first.

It is useful in exception catching when developing your own scripts. It may not occur when using default Django files.

1.2. ObjectDoesNotExist

This exception occurs when we request an object which does not exist. It is the base class for all the DoesNotExist Errors.

ObjectDoesNotExist emerges mainly from get() in Django.

Brief on get():

get() is an important method used to return data from the server. This method returns the object when found. It searches the object on the basis of arguments passed in the get(). If the get() does not find any object, it raises this error.

1.3. EmptyResultSet

This error is rare in Django. When we generate a query for objects and if the query doesn’t return any results, it raises this error.

The error is rare because most of the queries return something. It can be a false flag, but for custom lookups this exception is useful.

1.4. FieldDoesNotExist

This one is clear from its name. When a requested field does not exist in a model, this meta.get_field() method raises this exception.

Meta.get_field() method mediates between views and models. When the model objects are in view functions, Django uses this method for searching the fields. This method looks for the requested field in super_models as well. It comes in handy when we have made some changes to models.

1.5. MultipleObjectsReturned

When we expect a query to return a single response/ object but it returns more than one object, then Django raises this exception.

The MultipleObjectsReturned is also an attribute of models. It is necessary for some models to return multiple objects but for others, it cannot be more than one. This exception helps us to get more control over model data.

1.6. SuspiciousOperation

It is one of the security classes of Django. Django raises this error when it has detected any malicious activity from the user. This exception has many subclasses which are helpful in taking better security measures.

When anyone modifies the session_data, Django raises this exception. Even when there is a modification in csrf_token, we get this exception.

There are many subclasses, dealing with very particular problems. These subclasses are:

• DisallowedHost
• DisallowedModelAdminLookup
• DisallowedModelAdminToField
• DisallowedRedirect
• InvalidSessionKey
• RequestDataTooBig
• SuspiciousFileOperation
• SuspiciousMultipartForm
• SuspiciousSession
• TooManyFieldsSent

As we can see, all of them are very particular in some kind of data defect. These exceptions can detect various types of activities on the server. They have helped a lot of developers to build reliable and secure applications.

1.7. PermissionDenied

This exception is the clearest of all. You must have dealt with this exception while working on static files. Django raises this error when we store our static files in a directory which is not accessible.

You can raise this using the try/ except block but it will be more fun, the static files way. To raise it, change static folder settings to hidden or protected.

1.8. ViewDoesNotExist

We all have experienced this one. Websites have a very evolving frontend design and there are frequent modifications which can lead to some faulty urls.

Django checks for all urls and view function by default. If there is something wrong, the server will show an error.

But we can also raise this error when urls-config can’t get the view to load. It is a problem which occurs while using relative URL addressing.

1.9. MiddlewareNotUsed

Django is very useful at times. It raises this exception when an unused middleware is present in MIDDLEWARES list. It’s like the caching middleware. Whenever we have not implemented caching on our website, it will throw this exception.

All the middlewares present in our settings.py are utilized. Most of them are there for the admin app.

1.10. ImproperlyConfigured

You must have encountered this exception when configuring your first project. This exception is for the main settings.py file. If there are some incorrect settings in the main settings then this error will raise. It can also come up if the middlewares or modules do not load properly.

It is pretty helpful, as it saves us a lot of bugs.

1.11. FieldError

We raise field errors when models have some errors. For example: using the same name in a class is correct syntactically but it can be a problem for Django Models. Therefore, the exceptions will check for these kinds of things.

Cases like:

• Fields in a model defined with the same name
• Infinite loops caused by wrong ordering
• Invalid use of join, drop methods
• Fields name may not exist, etc.

1.12. ValidationError

We used the validation error in validating the form data. This class is a sub-class of django.core.exceptions class. It is extensively used to check data correctness. It will match the data with the model field or forms field. And, it ensures that no security threat is there due to illegal characters in user-input.

There can be validation errors which do not belong to any particular field in Django. They are NON_FIELD_ERRORS.

2. URL Resolver Exceptions

   This class is a major part of urls.py for defining urls. We import our path function from urls class.

   django.urls is one of the core classes of Django without which it might not function. This class also provides some exceptions:

   2.1. Resolver404

   We raise this exception if the path() doesn’t have a valid view to map. The Resolver404 shows us the error page. It is django.http.Http404 module’s subclass.

   2.2. NoReverseMatch

   It is a common occurrence. When we request for a URL which is not defined in our urls-config, we get this error.

3. Database Exceptions

   We can import these exceptions from django.db module. The idea behind this implementation is:

   Django wraps the standard database exceptions. And, when it happens, our Python code can correspond with the database exception. That makes it easy to deal with database exceptions in Python at a certain level.

   The exception wrappers provided by Django work in the same way as Python database API.

   The errors are:

• InterfaceError
• DatabaseError
• DataError
• IntegrityError
• InternalError
• ProgrammingError
• NotSupportedError

We raise these errors when:

• Database is not found
• Interface is not there
• Database is not connected
• Input data is not valid etc.

4. Http Exceptions

   We used this class in our first views. The HttpResponse is a sub-class of django.http class. The module provides some exceptions and special responses.

   UnreadablePostError

   This exception occurs when a user uploads a corrupt file or cancels an upload. In both cases, the file received by the server becomes unusable.

5. Transaction Exceptions

   A transaction is a set of database queries. It contains the smallest queries or atomic queries. When an error occurs at this atomic level, we resolve them by the django.db.transaction module.

   There are errors like TransactionManagementError for all transaction-related problems with the database.

6. Testing Framework Exceptions

   The django.test package also comes with many exceptions. We have also raised one exception from this class in our Django Redirect Tutorial.

   It is the infinite loop that we created with redirects. Check out that article’s last part.

7. Python Exceptions

   Django is a Python framework. Of course, we get all the pre-defined exceptions of Python as well. Python has a very extensive library of exceptions. And, you can also add more modules according to use-case.

Apply now for Advanced Python Training Course