On 12/16/2014 01:29 PM, Ben Sizer wrote:
Yeah, I can see from the code that it won't render a traceback (which is
probably why I chose to catch and rethrow it), but I was expecting to
see one from the debug toolbar saying where the 500 was raised from.

No. When an exception view "catches" an exception, the exception view renders something, and the exception doesn't bubble up outside of Pyramid-proper (the toolbar is "outside" of Pyramid in this case).


(Which is why I asked if there is any point to being able to raise these
error exceptions if the system doesn't attempt to note that you did so.)

You can register an exception view for a particular kind of exception and log, or do whatever else.

Apologies if I'm just completely misremembering this. It's possible that
I added the catch-and-raise code near the end of the time I was last
working on this project and just never saw what happens when it was
triggered.

Sure.

- C





On Tuesday, 16 December 2014 18:19:01 UTC, Chris McDonough wrote:

    On 12/16/2014 12:59 PM, Ben Sizer wrote:
     > I forgot to mention I was using Windows, so, good guess. ;)
     >
     > Anyway, this post inspired me to dig deeper and sprinkle some
    logging in
     > there liberally. And I've found the change: at one point, I catch
     > pymongo.errors.ConnectionFailure and raise
     > pyramid.httpexceptions.HTTPInternalServerError in its place. In the
     > past, I remember this still giving me a full traceback in
    development
     > mode - not on-screen, where it shows a plain 500 page, but in the
    debug
     > toolbar. Now it does not.
     >
     > I can't see any indication in the changelog of this behaviour having
     > changed though. Am I misremembering how it used to work? Is there
    any
     > worth in explicitly throwing server errors like this if there is no
     > logging that goes along with it?

    If you're catching a pymongo ConnectionFailure and turning it in to an
    HTTPInternalServerError, Pyramid's "default exception response view" is
    going to render it because that exception inherits from
    pyramid.httpexceptions.HTTPException which the default exception
    response view is also registered for, and no traceback will be shown
    (and certainly not the original traceback, which is lost when you catch
    it and reraise).  I can't remember a time when this was not true.

    - C


     >
     >
     >
     > On Monday, 15 December 2014 16:30:45 UTC, Jonathan Vanasco wrote:
     >
     >
     >     I've never used Pyramid under windows, so I could be off here...
     >
     >     But when running under Mac/Linux, one can trip 500x error
    that just
     >     says "Invalid Request" (or similar) under a few scenarios:
     >
     >     • exceptions in the wsgi middleware stack
     >     • exceptions in most areas of the debugtoolbar code
     >     • exceptions in very few areas of pyramid code(I think mostly in
     >     certain Events and Tweens)
     >
     >     For the debugtoolbar to work (and show you the traceback) it
    needs
     >     to catch the exception. It can't catch the middleware errors,
    and
     >     raising exceptions in certain parts of pyramid code will not
    have a
     >     proper environment for the tracebacks to work.  So these errors
     >     appear in the process log, but are inaccessible to the
     >     toolbar/interactive traceback mechanism. It sounds to me like
    this
     >     is what you're experiencing.
     >
     >     Are you using any Event Subscribers ?  ( I think I've triggered
     >     stuff like this with NewResponse can cause this )  I recall
    tweens
     >     having issues too.   I think I also caused this with an
    exception in
     >     an __init__() function when using Class-based views.
     >
     > --
     > You received this message because you are subscribed to the Google
     > Groups "pylons-discuss" group.
     > To unsubscribe from this group and stop receiving emails from it,
    send
     > an email to pylons-discus...@googlegroups.com <javascript:>
     > <mailto:pylons-discuss+unsubscr...@googlegroups.com <javascript:>>.
     > To post to this group, send email to pylons-...@googlegroups.com
    <javascript:>
     > <mailto:pylons-...@googlegroups.com <javascript:>>.
     > Visit this group at http://groups.google.com/group/pylons-discuss
    <http://groups.google.com/group/pylons-discuss>.
     > For more options, visit https://groups.google.com/d/optout
    <https://groups.google.com/d/optout>.

--
You received this message because you are subscribed to the Google
Groups "pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send
an email to pylons-discuss+unsubscr...@googlegroups.com
<mailto:pylons-discuss+unsubscr...@googlegroups.com>.
To post to this group, send email to pylons-discuss@googlegroups.com
<mailto:pylons-discuss@googlegroups.com>.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

--
You received this message because you are subscribed to the Google Groups 
"pylons-discuss" group.
To unsubscribe from this group and stop receiving emails from it, send an email 
to pylons-discuss+unsubscr...@googlegroups.com.
To post to this group, send email to pylons-discuss@googlegroups.com.
Visit this group at http://groups.google.com/group/pylons-discuss.
For more options, visit https://groups.google.com/d/optout.

Reply via email to