No error at 404 page when context processor returns None.

[lcd1232]

It's difficult to find a bug if page has no stack trace or readable error. I caught this error if I do not return anything from the context processor. It would be great if Django will add a readable error for this situation.

If you have a custom 404 template and page not found then you got 500 error without understanding why.

Reproducible application - ​https://gist.github.com/lcd1232/f242d88b1eaeaccbb6ba2e81e68644cd

One more example of a context processor that can generate the same error:

def url_info(request):
    """
    Adds url info.
    """
    info = resolve(request.path_info) # raised exception for 404 page
    return {
        "url_info": {
            "app_name": info.namespace,
            "url_name": info.url_name,
            "full_name": f"{info.namespace}:{info.url_name}"
        }
    }

[Mariusz Felisiak]

It's clearly stated in ​docs that "Each context processor must return a dictionary.". IMO we shouldn't add extra checks for not supported implementation, see comment. Also a bug in your implementation is quite easy to understand in the DEBUG mode, it raises:

  File "django/template/context.py", line 244, in bind_template
    updates.update(processor(self.request))

Exception Type: TypeError at /admin/login/
Exception Value: 'NoneType' object is not iterable

[lcd1232]

Ok. And what about adding this check for the system check framework?

[Mariusz Felisiak]

Replying to lcd1232:

Ok. And what about adding this check for the system check framework?

I'm against this, we cannot add a system check for any unsupported usage. Also I'm not sure if it's doable, because a context processor can return None only under certain circumstances. You can start a discussion on DevelopersMailingList if you don't agree.

[Timothy Schilling]

The debug toolbar has hit this case a few times and it's a painful for the maintainers to determine this is the reason the toolbar doesn't function. Perhaps we can add more emphasis around the need to have to return a dictionary? For example maybe adding a comment within the code example that was introduced in v3.2 that says # A dictionary must always be returned. This would be similar to how the form clean_[field] ​documentation informs developers about returning the cleaned data.