[issue29183] Unintuitive error handling in wsgiref when a crash happens in write() or close()

Change by Berker Peksag : -- components: +Library (Lib) resolution: -> fixed stage: patch review -> resolved status: open -> closed versions: +Python 3.7, Python 3.8 -Python 2.7, Python 3.4, Python 3.5, Python 3.6 ___ Python tracker

[issue29183] Unintuitive error handling in wsgiref when a crash happens in write() or close()

Berker Peksag added the comment: New changeset f393e8eb463d60ce559982613429568c518ab8d9 by Berker Peksag (Miss Islington (bot)) in branch '3.7': bpo-29183: Fix double exceptions in wsgiref.handlers.BaseHandler (GH-12914) https://github.com/python/cpython/commit/f393e8eb463d60ce559982613429568

[issue29183] Unintuitive error handling in wsgiref when a crash happens in write() or close()

Berker Peksag added the comment: New changeset 7c59362a15dfce538512ff1fce4e07d33a925cfb by Berker Peksag in branch 'master': bpo-29183: Fix double exceptions in wsgiref.handlers.BaseHandler (GH-12914) https://github.com/python/cpython/commit/7c59362a15dfce538512ff1fce4e07d33a925cfb

[issue29183] Unintuitive error handling in wsgiref when a crash happens in write() or close()

Change by miss-islington : -- pull_requests: +13334 ___ Python tracker ___ ___ Python-bugs-list mailing list Unsubscribe: https://m

[issue29183] Unintuitive error handling in wsgiref when a crash happens in write() or close()

Change by Berker Peksag : -- keywords: +patch pull_requests: +12840 stage: -> patch review ___ Python tracker ___ ___ Python-bugs-l

[issue29183] Unintuitive error handling in wsgiref when a crash happens in write() or close()

Martin Panter added the comment: There are actually two “close” methods in the WSGI package: ServerHandler’s implementation extends the BaseHandler implementation. Making the “close” methods do nothing if called a second time would avoid the error about “self.status” being None, but won’t hel

[issue29183] Unintuitive error handling in wsgiref when a crash happens in write() or close()

Chris Jerdonek added the comment: This may or may not be the same as what you're suggesting, Martin. But is another option to make close() a no-op if it is called a second time? Otherwise, it seems we'd need to make sure that no code path can result in close() being called twice (even during

[issue29183] Unintuitive error handling in wsgiref when a crash happens in write() or close()

Martin Panter added the comment: Looks like the error handling is broken by Issue 16220, which calls the “BaseHandler.close” method before the exception is caught for the error handler. Perhaps it is better to just close the iterator without messing with the other attributes in the exception

[issue29183] Unintuitive error handling in wsgiref when a crash happens in write() or close()

New submission from Jerome Leclanche: TLDR: When an error happens in the wsgiref's write() or close(), stack traces get inundated with irrelevant yet legitimate errors which make it hard to track down the real issue. Couple of examples of this happening in practice: https://stackoverflow.com/q