【发布时间】:2015-03-11 08:54:39
【问题描述】:
以前运行良好的应用程序在使用文件浏览器应用程序时开始在我的应用程序中引发“错误请求 (400)”。该应用程序设置为 DEBUG=True,其他地方的错误会引发预期的厄运黄屏。将设置与旧版本区分开来告诉我那里没有任何改变,并且文件设置指向正确的目录,我认为排除了 Django FileBrowser 400 Error 作为解释。这肯定使用工作。问题既不是控制台也不是我安装中其他地方出现的错误转储页面,只是简洁的错误请求页面。
我承认这些信息不足以调试错误本身,坦率地说,我不知道去哪里找。
我的问题是;- 当这种情况发生时,有没有办法在它引发 400 并调试它时捕获它。当我需要检查程序状态时,我在其他情况下使用 ipdb,但这甚至没有给我足够的信息来知道在哪里放置断点!
附加
为避免混淆,Debug 设置为 True,日志记录配置为转储到控制台,所有控制台显示为
[11/Mar/2015 16:58:48] "GET /admin/filebrowser/browse/?pop=1 HTTP/1.1" 400 26
【问题讨论】:
-
您是否阅读过docs.djangoproject.com/en/1.7/howto/error-reporting 并特别设置了
ADMINS变量? (docs.djangoproject.com/en/1.7/ref/settings/#std:setting-ADMINS)。 Django 可以在出错时向您发送完整的堆栈跟踪。 -
仅在调试设置为故障时适用。日志记录被配置为转储到控制台。所有控制台获取的都是鲜红色;- [11/Mar/2015 16:58:48] "GET /admin/filebrowser/browse/?pop=1 HTTP/1.1" 400 26
-
谢谢,我阅读了
DEBUG=True。这很奇怪,您应该在错误页面上获得完整的跟踪。 -
它似乎是 base.py 中的回归。见code.djangoproject.com/ticket/21668