On Fri, Jan 7, 2011 at 12:10 AM, Marius Gedminas <[email protected]> wrote:
> On Thu, Jan 06, 2011 at 04:04:06PM -0800, Justin Francis wrote:
>> I have recently started using Pylons and am having trouble finding
>> information about the exact structure of the error handling stack.
>> When an exception occurs anywhere, what is the sequence of calls that
>> Pylons makes (from the time the exeception occurs until the error
>> screen is shown)? How does this sequence differ between debug mode and
>> release mode?

The Pylons Execution Analysis has been updated for Pylons 1. I
submitted it to the Pylons documentation but it hasn't made it there
yet.
https://bitbucket.org/sluggo/pyramid-docs/src/7377b97895ad/execution.rst

(The repository is renamed pyramid-docs, but rest assured that this
article is for Pylons 1.)

Exceptions are handled differently depending on where they occur. It's
difficult to trace exactly where all the try/except handlers are and
what they catch. But for exceptions that occur during a controller
action or in request routing, which are the most common kind, the
ErrorHandler middleware catches them. This is
pylons.middleware.ErrorHandler in middleware.py. If 'debug' is true in
the INI file, the error handler delegates to
weberror.evalexception.EvalException, which produces the interactive
traceback. If 'debug' is false, it delegates to
weberror.errormiddleware.ErrorMiddleware, which emails the traceback
(if configured in the INI) or dumps it to stderr, sets the HTTP status
to 500 (Internal Server Error), and I think creates a simple HTML
error page.

If the application returns a 4xx or 5xx status, including by calling
abort() and I think by raising Paste's HTTPNotFound, etc, the
StatusCodeRedirect middleware intercepts it, makes a subrequest for a
beautiful error document, and sends that to the user. I hate those
beautiful error documents with stylesheets and images, so I comment
out StatusCodeRedirect in all my applications.

If an exception occurs at too low a low level for the middleware to
catch it, you simply get "Internal Server Error" in teletype text in
the browser, and a traceback in the console. I assume PasteHTTPServer
does that itself.

For even lower-level errors like an invalid INI file or where
PasteHTTPServer can't catch it, you get a normal Python traceback and
abort in the console.

> That's an excellent question.  I've had this exact wish (figure out the
> description of Pylons error handling) for a long time now in my
> todo-list.
>
>> This leads me to my question: I want to do a custom cleanup right
>> before Pylons displays the error page. I have some database objects on
>> which I want to issue a Rollback(). Where in the Pylons code would I
>> place this rollback, so that it gets called whenever Pylons handles an
>> exception?
>
> Traditionally you'd do this in BaseController.__call__:
>
>    def __call__(self, environ, start_response):
>        try:
>            return WSGIController.__call__(self, environ, start_response)
>        except:
>            # do your error cleanup
>            raise
>        finally:
>            # do your cleanup that's suitable for both errors and normal
>            # requests, e.g. sqlalchemy's
>            meta.Session.remove()

This is what most people do. However, i've sometimes gotten an error
when the database raises an exception and you don't explicitly call
rollback afterward. It may be specific to PostgreSQL. So you may want
to do:

meta.Session.rollback()
meta.Session.remove()

>
> Marius Gedminas
> --
> One could envision a different approach to persistence (hands wave and
> magical stardust appears overhead to percussive indian string music)
> where objects in the database were proxied rather than deriving from a
> common base class.
>        -- Casey Duncan
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.10 (GNU/Linux)
>
> iEYEARECAAYFAk0myl4ACgkQkVdEXeem14/z0gCfdDLjWuHihyyINEVPACLYHSoV
> ErsAmwbO3vgKEC1urmDTjDhWE1Ghv3ET
> =/4o7
> -----END PGP SIGNATURE-----
>
>



-- 
Mike Orr <[email protected]>

-- 
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to 
[email protected].
For more options, visit this group at 
http://groups.google.com/group/pylons-discuss?hl=en.

Reply via email to