The NewResponse subscriber will not be executed if you don't have an exception view unless it executes before the exception occurs. Maybe you need to post an example application with the behavior you're seeing. There's 2 code paths... 1) serving a request in normal operation, and 2) for handling an exception view. When an exception occurs during path 1, you drop into path 2 and never go back to path 1. When an exception occurs in path 2, pyramid gives up and leaves it for the wsgi stack to deal with.
With this in mind, I'm not sure how you intend to track exceptions in pyramid without an exception view? I think you're getting confused about which code path you're seeing the NewResponse subscriber on. On Wed, Mar 21, 2012 at 1:38 PM, Jonathan Vanasco <[email protected]>wrote: > > > On Mar 21, 2:11 pm, Michael Merickel <[email protected]> wrote: > > > The only way a NewResponse subscriber would be invoked *after* an > exception > > occured is if you are handling the exception in an exception view. If > > that's the case, then you are rendering a new view and as part of the > > rendering, NewResponse will be invoked, and request.exception will be the > > exception. > > Right. > > My point is that if you don't use an Exception View, you don't seem to > have the ability to track your exceptions > > @view_config(route_name="hello_world",renderer='hello_world.mako') > def hello_world(): > #return {'project':'example'} > raise ValueError('example') > > If I create an Exception View with "context=ValueError" , I'm able to > see in a NewResponse event that request.exception=ValueError > > If I don't use an Exception View , then NewReponse does have a > request.exception attribute -- but it is set to None. So I know that > an Exception happened (in general)- and I can do some amount of > processing based on that, but I don't know what exception occurred or > where. > > If the raised exception were stashed onto the event object, you could > quickly and easily have an event subscriber that handles all > exceptions. > > > > from sqlalchemy.exc import OperationalError as > > > SqlAlchemyOperationalError > > > > > @view_config(context=SqlAlchemyOperationalError) > > > def failed_sqlalchemy(exception , request): > > > """do whatever here" > > > pass > > > > This is an actual view, so you need to return a response object, or a > dict > > usable by a configured renderer. > > yep, i knew that. thanks! > > -- > 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. > > -- 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.
