django - handler404 vs handler500答案

【问题标题】：django - handler404 vs handler500django - handler404 vs handler500
【发布时间】：2014-08-21 14:39:26
【问题描述】：

我现在有点困惑。

我可以覆盖 Django 中的 handler404 和 handler500。我想，我可以这样做：

try:
   mymodel = MyModel.objects.get(id=someid)
except MyModel.DoesNotExist:
   raise Http404

但我很想知道究竟是什么导致了这个 404 - 服务器错误或只是一个错误的 URL..

这怎么可能？我可以在 handler404 中获得有关 500 错误的信息吗？

如果是 500，handler500 确实有一个 RequestContext，而像 {{STATIC_URL}} 这样的东西将在 500.html 中停止工作。这就是为什么我想，我会改为提出 404 并向 404 处理程序内的管理员发送有关错误的电子邮件。这有意义吗？

【问题讨论】：

这个问题很困惑。 Handler404是针对404错误，即未找到。 500 表示服务器错误。
@DanielRoseman 是的，但是raise Http404 给出的结果与一些错误的 url 相同。我的问题是，即使出现 500 个错误，我是否通过提高 404 做得对。如果是这样，如果它真的是 404 或 500，我想了解更多信息。
raise Http404 的作用与未找到相同，因为它是在未找到页面时启动的。当你自己提出错误 5xx 时，你能举个例子吗？错误 5xx 的处理程序用于在服务器端出现问题时显示页面 - 此时 django 向管理员（settings.ADMINS）发送电子邮件并提供详细信息。
@DimmuR 这就是重点。我没有筹集任何 500。相反，我只筹集了 404。:(

【解决方案1】：

底线是这样的：

为了生成/引起/提高 500，您必须请求一个有效的 URL。

这很简单 - 只有在没有 500 错误的情况下才会引发 404，因为 500 错误不会阻止链接有效。

因此，如果它是 404，它就没有机会也提高 500；因为没有您请求有效的 URL，就不会运行服务器端代码；因此这不能触发 500。

它们是相互排斥的。

在您的特定情况下，会发生以下情况：

您请求/foo/bar/1
此 URL 使用 url 模式映射到视图，如果匹配 - 就是这样，您不再有机会引发 404。
请求被传递给处理程序 - 现在，在这个阶段，请求管道无法生成 404。
您的视图代码中存在错误 - 现在可能会发生以下两种情况之一：
1. 您可以通过 try/except 预料到此错误，然后您可以提出任何问题你喜欢的例外。如果此异常也返回响应，那么无论该响应是 - 这是您在回复客户时发回的错误代码。所以，当你raise Http404 时，它会返回一个带有 404 错误代码的响应。您可以愉快地返回任何其他响应和错误代码组合。
2. 发生了您的代码未捕获的错误，或者您的代码未返回正确的响应。在这种情况下，django 的默认异常处理程序将返回响应并引发 500。这是正常/默认情况。

从流程中可以看出，无论如何，要返回 500 响应，URL 必须是有效的。

【讨论】：

好的。所以在 500 的情况下，我的 500.html 只是被破坏了。解决方案是什么？我从来没有在其他网站看到过 500 的页面，是因为他们的代码完美还是他们显示 404 而不是显示 500？
您的500.html 只有在调试设置为 false 的情况下才会显示，否则调试处理程序将运行，这就是向您显示执行跟踪的内容。因此，关闭调试模式，当您（或 django）返回 5xx 错误代码时，您的 500 错误页面将显示。
谢谢，现在我明白它是如何工作的了。但是我关于RequestContext - {{STATIC_URL}} 的问题仍然悬而未决。如果我关闭调试，它将在服务器中显示 500.html（而不是在 dev 中），但在 500 的情况下，{{STATIC_URL}} 不起作用。我该如何处理？
作为最佳实践，你不应该让你的 500 或 404 页面依赖于你的服务器代码——也就是说，即使没有服务器存在，它们也应该可以工作。一些公司在 Amazon S3 上托管他们的 500 和 404 页面，这样即使他们的服务器完全关闭，至少也会发送一个响应。底线 - 如果必须的话，“硬编码”路径，但要让 500 页尽可能简单和独立。
啊，非常感谢。现在我对另一个解决方法有了更多了解。