我的自定义中间件类在响应周期中似乎跳过了process_exception
阶段
from django.utils.deprecation import MiddlewareMixin
class MyMiddleware(MiddlewareMixin):
def process_request(self, request):
print("Request!")
def process_response(self, request, response):
print("Response!")
return response
def process_exception(self, request, exception):
print("Exception!")
已配置中间件。...
DJANGO_MIDDLEWARE = [
'django.middleware.security.SecurityMiddleware',
'django.contrib.sessions.middleware.SessionMiddleware',
'corsheaders.middleware.CorsMiddleware',
'django.middleware.common.CommonMiddleware',
'django.middleware.csrf.CsrfViewMiddleware',
'django.contrib.auth.middleware.AuthenticationMiddleware',
'django.contrib.messages.middleware.MessageMiddleware',
'django.middleware.clickjacking.XFrameOptionsMiddleware',
'debug_toolbar.middleware.DebugToolbarMiddleware',
]
LOCAL_MIDDLEWARE = [
'path.to.MyMiddleware',
]
MIDDLEWARE = DJANGO_MIDDLEWARE + LOCAL_MIDDLEWARE
并隐藏在我的查看代码中:
def some_view(request):
...
raise Exception("foo")
但是,当我点击url时,会在控制台日志中得到它:
Request!
Internal Server Error: /my/url/
Traceback (most recent call last):
... long traceback ...
File "/path/to/my/views.py", line 184, in some_view
raise Exception("foo")
Exception: foo
ERROR django.request 2019-01-24 11:50:48,270 [exception.py handle_uncaught_exception 118] Internal Server Error: /my/url/
Traceback (most recent call last):
... long traceback ...
File "/path/to/my/views.py", line 184, in some_view
raise Exception("foo")
Exception: foo
Response!
如您所见,process_exception
和process_request
都没有被调用。出于某种原因,在我的中间件process_response
被击中之前,异常回溯就显示了两次。传递给我的中间件的process_response
的响应是标准的Django 500调试页面,表明该异常已得到处理,但我的印象是将中间件列为列表的最后一个意味着应该在响应周期中第一个被访问?
编辑因此,在进一步播放时,这似乎与DjangoDebugToolbar有关,当我禁用它并删除中间件时,我的中间件工作正常。我对此感到困惑,因为我的中间件应该首先触发。
EDIT 2 具体来说,它似乎是配置面板吗?评论出来解决了这个问题...多么奇怪
答案 0 :(得分:0)
因此,我最终找到了https://github.com/jazzband/django-debug-toolbar/issues/497,它在Django调试工具栏中的“分析”面板中将其列为错误。令人沮丧的是,它以一种非常明显的方式破裂。
修复方法是:不要使用概要分析面板,或者将Django调试工具栏放在中间件列表的最后,并接受DDT不会监视您的任何中间件类