entrouvert
/
debian-python-raven
17
0
Fork 0
Code Issues Pull Requests Releases Activity

Log SystemExit in wsgi middleware when code != 0 

SystemExit does not subclass Exception, so we don't catch this.
SystemExit manifests itself (at least) from gunicorn when gunicorn
attempts to gracefully shut down a worker process. See GH-675 for more
background.

Fixes: GH-675
This commit is contained in:
Matt Robenolt 2015-11-12 17:20:16 -08:00
parent 276266822a
commit 3eddaa4dff
1 changed files with 12 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

12
raven/middleware.py
View File

@ -36,6 +36,10 @@ class Sentry(object):
except Exception:
self.handle_exception(environ)
raise
except SystemExit as e:
if e.code != 0:
self.handle_exception(environ)
raise
try:
for event in iterable:
@ -43,6 +47,10 @@ class Sentry(object):
except Exception:
self.handle_exception(environ)
raise
except SystemExit as e:
if e.code != 0:
self.handle_exception(environ)
raise
finally:
# wsgi spec requires iterable to call close if it exists
# see http://blog.dscpl.com.au/2012/10/obligations-for-calling-close-on.html
@ -51,6 +59,10 @@ class Sentry(object):
iterable.close()
except Exception:
self.handle_exception(environ)
except SystemExit as e:
if e.code != 0:
self.handle_exception(environ)
raise
self.client.context.clear()
def get_http_context(self, environ):