Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > comp.lang.python > #85795 > unrolled thread

Assigning a function to sys.excepthook doesn't work in WSGI

Back to article view | Back to comp.lang.python

Contents

  Assigning a function to sys.excepthook doesn't work in WSGI tak.govoril@gmail.com - 2015-02-18 07:08 -0800
    Re: Assigning a function to sys.excepthook doesn't work in WSGI Ian Kelly <ian.g.kelly@gmail.com> - 2015-02-18 09:51 -0700
      Re: Assigning a function to sys.excepthook doesn't work in WSGI Alexander Sh <tak.govoril@gmail.com> - 2015-02-18 11:16 -0800

#85795 — Assigning a function to sys.excepthook doesn't work in WSGI

I want to generate an html page with http response status '200 OK' in case of an uncaught exception in my wsgi application, instead of web server's standard '500 Internal Server Error' response for such case. To do so, I've made the following sample code:

import sys

def application(environ, start_response):
    def exception(etype, evalue, trace):
        start_response('200 OK', [('Content-Type', 'text/plain')])
        return ['Error']

    sys.excepthook = exception

    1/0

    start_response('200 OK', [('Content-Type', 'text/plain')])
    return ['OK']

But the function 'exception' is never called, and a standard '500 Internal Server Error' response is still generated by server in case of an uncaught exception.

I looked through the documentation, but unable to find the answer. Are there any ways to handle uncaught by try..except exceptions under mod_wsgi?

[toc] | [next] | [standalone]

#85799

On Wed, Feb 18, 2015 at 8:08 AM,  <tak.govoril@gmail.com> wrote:
> I want to generate an html page with http response status '200 OK' in case of an uncaught exception in my wsgi application, instead of web server's standard '500 Internal Server Error' response for such case. To do so, I've made the following sample code:
>
> import sys
>
> def application(environ, start_response):
>     def exception(etype, evalue, trace):
>         start_response('200 OK', [('Content-Type', 'text/plain')])
>         return ['Error']
>
>     sys.excepthook = exception
>
>     1/0
>
>     start_response('200 OK', [('Content-Type', 'text/plain')])
>     return ['OK']
>
> But the function 'exception' is never called, and a standard '500 Internal Server Error' response is still generated by server in case of an uncaught exception.

sys.excepthook is called just before the interpreter exits due to an
exception. In a mod_wsgi environment, having the interpreter exit just
because of an exception would be undesirable. I don't know exactly
what it's doing under the hood, but I would assume that the exception
never makes it to sys.excepthook because the gateway itself is
catching the exception in order to generate the 500 response.

> I looked through the documentation, but unable to find the answer. Are there any ways to handle uncaught by try..except exceptions under mod_wsgi?

Here is what PEP 3333 has to say about error handling:
https://www.python.org/dev/peps/pep-3333/#error-handling

[toc] | [prev] | [next] | [standalone]

#85810

On Wednesday, February 18, 2015 at 7:52:19 PM UTC+3, Ian wrote:
> 
> sys.excepthook is called just before the interpreter exits due to an
> exception. In a mod_wsgi environment, having the interpreter exit just
> because of an exception would be undesirable. I don't know exactly
> what it's doing under the hood, but I would assume that the exception
> never makes it to sys.excepthook because the gateway itself is
> catching the exception in order to generate the 500 response.
> 
> > I looked through the documentation, but unable to find the answer. Are there any ways to handle uncaught by try..except exceptions under mod_wsgi?
> 
> Here is what PEP 3333 has to say about error handling:
> https://www.python.org/dev/peps/pep-3333/#error-handling

Thank you for your reply, it clarifies everything. 
Actually, I've missed that PEP in my studies.

[toc] | [prev] | [standalone]

Back to top | Article view | comp.lang.python

csiph-web