0
0
Djangoframework~20 mins

Exception middleware in Django - Practice Problems & Coding Challenges

Choose your learning style9 modes available
Challenge - 5 Problems
🎖️
Exception Middleware Master
Get all challenges correct to earn this badge!
Test your skills under time pressure!
component_behavior
intermediate
2:00remaining
What happens when an exception is raised in Django middleware?

Consider a Django middleware that catches exceptions during request processing. What is the typical behavior when an exception is raised inside the __call__ method of middleware?

Django
class ExceptionMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        try:
            response = self.get_response(request)
        except Exception as e:
            return self.handle_exception(request, e)
        return response

    def handle_exception(self, request, exception):
        return HttpResponse('Error handled', status=500)
AThe middleware ignores the exception and lets it propagate to the next middleware or view.
BThe middleware catches the exception and returns a custom error response without crashing the server.
CThe middleware logs the exception but still returns the original response from the view.
DThe middleware crashes the server immediately without returning any response.
Attempts:
2 left
💡 Hint

Think about how exception handling works in Python and how middleware can intercept errors.

📝 Syntax
intermediate
2:00remaining
Identify the syntax error in this Django exception middleware snippet

Which option contains a syntax error that will prevent this middleware from running?

Django
class ExceptionMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        try
            response = self.get_response(request)
        except Exception as e:
            return self.handle_exception(request, e)
        return response

    def handle_exception(self, request, exception):
        return HttpResponse('Error', status=500)
AMissing parentheses in HttpResponse call.
BIncorrect indentation of the except block.
CMissing self parameter in handle_exception method.
DMissing colon after try statement.
Attempts:
2 left
💡 Hint

Check the syntax of the try-except block carefully.

🔧 Debug
advanced
2:00remaining
Why does this exception middleware fail to catch exceptions?

Given the following middleware, why does it fail to catch exceptions raised in views?

Django
class ExceptionMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def process_exception(self, request, exception):
        return HttpResponse('Exception caught', status=500)

    def __call__(self, request):
        response = self.get_response(request)
        return response
ABecause <code>process_exception</code> is never called unless middleware is old-style and registered properly.
BBecause <code>__call__</code> method does not have a try-except block to catch exceptions.
CBecause the middleware does not import HttpResponse.
DBecause the middleware returns the response before calling <code>process_exception</code>.
Attempts:
2 left
💡 Hint

Think about how Django calls process_exception and middleware styles.

state_output
advanced
2:00remaining
What is the response status code after exception handling in this middleware?

What status code will the client receive when an exception is raised in the view and handled by this middleware?

Django
class ExceptionMiddleware:
    def __init__(self, get_response):
        self.get_response = get_response

    def __call__(self, request):
        try:
            response = self.get_response(request)
        except Exception:
            return HttpResponse('Handled error', status=418)
        return response
A200
B500
C418
D404
Attempts:
2 left
💡 Hint

Look at the status code set in the HttpResponse returned on exception.

🧠 Conceptual
expert
2:00remaining
Which middleware order ensures exception middleware catches errors from all views and other middleware?

In Django, middleware order matters. Where should exception middleware be placed in the MIDDLEWARE list to catch exceptions from all views and other middleware?

AAt the very beginning (first in the list).
BAt the very end (last in the list).
CIn the middle, after authentication middleware.
DAnywhere, order does not affect exception catching.
Attempts:
2 left
💡 Hint

Think about how Django processes middleware in order and how exceptions propagate.