Apache 错误日志中出现未知 Django (Postgis) 异常，没有电子邮件报告
我正在使用 Apache + mod_wsgi 运行多个 Django 站点。现在，我刚刚在 Apache 错误日志之一中看到以下错误：
[Mon Aug 22 16:12:01 2011] [error] Exception AttributeError: "'NoneType' object has no attribute 'finishGEOS_r'" in <bound method GEOSContextHandle.__del__ of <django.contrib.gis.geos.prototypes.threadsafe.GEOSContextHandle object at 0xb9641f0c>> ignored
奇怪的是，我根本没有从 Django 收到任何有关此异常的邮件错误报告（所有站点都以 DEBUG=false 运行并且ADMINS 列表中的正确邮件地址）。
有谁知道什么可能导致此错误？ 尾随的 >> 是否ignored 表示异常被忽略，用户没有得到 HTTP 500 页面？
I am running several Django sites using Apache + mod_wsgi. Now, I've just seen the following error in one of the Apache error logs:
[Mon Aug 22 16:12:01 2011] [error] Exception AttributeError: "'NoneType' object has no attribute 'finishGEOS_r'" in <bound method GEOSContextHandle.__del__ of <django.contrib.gis.geos.prototypes.threadsafe.GEOSContextHandle object at 0xb9641f0c>> ignored
The strange thing is, that I don't get any mail error reports from Django at all concerning this exception (all the sites run with DEBUG=false and correct mail adresses in the ADMINS list).
Does anyone know what could cause this error?
Does the trailing >> ignored means that the exception is ignored and the user doesn't get a HTTP 500 page?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我相信这只是一条
logging.error消息，而不是 500see
http://python.6.n6.nabble.com/Re-Django-13843-destroy-geom-filling-up-the-apache-error-logs-tt365140.html#none
如果您使用 Apache，错误日志无论如何都会告诉您该请求的 http 状态，以便您可以查看用户是否收到 500 错误？
I believe it's just a
logging.errormessage rather than a 500see
http://python.6.n6.nabble.com/Re-Django-13843-destroy-geom-filling-up-the-apache-error-logs-tt365140.html#none
if you're on Apache the error log should tell you the http status of that request anyway, so you can see if the user got a 500 error?
如果我的记忆不错，如果析构函数方法作为异常的副作用被调用，并且析构函数中发生了进一步的异常，那么Python将无法传播新的异常，因此Python会将其直接记录到stderr。最初的异常仍然是引发的异常。这就是为什么你不会看到后者被 Django 捕获并通过电子邮件发送到 ADMINS 列表等。
If my memory is good, if a destructor method is being invoked as a side effect of an exception, and a further exception occurs within the destructor then Python can't propagate the new one and so Python will log it itself direct to stderr. The original exception is then still the one that is raised. This is why you will not see the latter captured by Django and emailed out to ADMINS list etc.