Exception handling in pyramid is pretty straightforward. If an exception occurs for the first time, and isn't caught by your code, then pyramid will perform view lookup using that exception as the context. Those views can have their own renderers, permissions and predicates. If another unhandled exception occurs or no matching exception view is found, it leaves pyramid and bubbles up the wsgi stack where the server usually turns it into a 500.
While the exception view is being handled, request.exception and request.exc_info should be populated (at least on 1.3+), so you could deal with that in a NewResponse subscriber if necessary. On Wed, Mar 21, 2012 at 12:10 PM, Jonathan Vanasco <jonat...@findmeon.com>wrote: > I'm using pyramid and SqlAlchemy, but not pyramid_tm. > > If the server is down, the following exception is raised: > sqlalchemy.exc.OperationalError > > I'm wondering how i can best catch this , so i can handle internal > alerts and possibly change the response. > > the only thing available in a NewResponse subscriber is : > event.request.exception = None > > examining all of the objects in event, the actual error isn't logged > anywhere ( as its not an Exception View ). does anyone have a clue on > another approach i can take ? > > -- > You received this message because you are subscribed to the Google Groups > "pylons-discuss" group. > To post to this group, send email to pylons-discuss@googlegroups.com. > To unsubscribe from this group, send email to > pylons-discuss+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-discuss?hl=en. > > -- You received this message because you are subscribed to the Google Groups "pylons-discuss" group. To post to this group, send email to pylons-discuss@googlegroups.com. To unsubscribe from this group, send email to pylons-discuss+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-discuss?hl=en.
