catching sqlalchemy exceptions

[Jonathan Vanasco]

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 ?

[Michael Merickel]

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.

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

[Jonathan Vanasco]

Could you correct me if I'm wrong in interpreting your remarks:

I could create a new view , and then just forget about the NewResponse
subscriber ?

The way the 'uncaught' exception bubbles up is a little weird -- it
doesn't seem to exist anywhere within the event. It just gets marked
as "None" ( vs the request not having an attribute ). it would be
really useful if it was logged.

-----
from sqlalchemy.exc import OperationalError as
SqlAlchemyOperationalError

@view_config(context=SqlAlchemyOperationalError)
def failed_sqlalchemy(exception , request):
"""do whatever here"
pass

On Mar 21, 1:32 pm, Michael Merickel <mmeri...@gmail.com> wrote:
> 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.
>

[Michael Merickel]

On Wed, Mar 21, 2012 at 1:06 PM, Jonathan Vanasco <jona...@findmeon.com> wrote:

The way the 'uncaught' exception bubbles up is a little weird -- it
doesn't seem to exist anywhere within the event.  It just gets marked
as "None" ( vs the request not having an attribute ). it would be
really useful if it was logged.

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.

 

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. 

[Jonathan Vanasco]

On Mar 21, 2:11 pm, Michael Merickel <mmeri...@gmail.com> 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!

[Michael Merickel]

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.

[Jonathan Vanasco]

https://github.com/jvanasco/pyramid_exceptionstest

If you hit /hello_world it raises a ValueError.
There is no Exception View configured for ValueError.
The NewResponse subscriber catches it.

[Jonathan Vanasco]

nearly 2 months later, i figured this out.

my errors were due to the debug system being enabled in
development.ini

the NewResponse subscriber is not caught in production.ini

i'll flag this on the devel mailing list, as the docs for
NewSubscriber or the Debug should reflect this.