【问题标题】:How to trap Django 400 error如何捕获 Django 400 错误
【发布时间】: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

【问题讨论】:

标签: python django debugging


【解决方案1】:

好的,我找到了答案。

我似乎以某种方式触发了“可疑操作”(看起来实际上是由于Django FileBrowser 400 Error),但是错误被不合理地抑制了。这个错误票解决了它:

https://code.djangoproject.com/ticket/21668

最后的变更集修复了它(但是我不得不在最后删除 status_code 参数,是否已弃用?)

如果有人对发生这种情况的其他情况有更一般的答案,我会将你的答案设置为接受的答案。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2014-10-12
    • 2013-01-16
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多