Documentation Suggestions for Subscribers or Debug
I ran into an issue a few months ago regarding a NewResponse subscriber and failing to catch errors ( https://groups.google.com/group/pylons-discuss/browse_thread/thread/54b5b3eb5e2ccfe/4e9a2abc09b9651f ) As I prepare for a production release , my old code ( which i forgot to remove ) started firing -- and I finally figured out what was happening. Because I had debugging turned on via 'development.ini', Pyramid was catching the error & response object from the app, and replacing it with its own. In a perfect world, the Pyramid debug system would let the original response/request stuff somehow persist -- so code can be written that works on production and development. In a less perfect, though perfectly acceptable world, it would be great if the debug & event subscriber docs cross-referenced one another with an alert/note box that simply states that the debug system will 'overtake' the response object when turned on, and subscribers that are designed to handle errors may not work as desired when debugging is enabled. -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Documentation Suggestions for Subscribers or Debug
What? Pyramid doesn't have a "debug" code path, minus emitting some log messages. Do you mean that the debugtoolbar is doing something to the response? On Tue, May 15, 2012 at 5:57 PM, Jonathan Vanasco wrote: > I ran into an issue a few months ago regarding a NewResponse > subscriber and failing to catch errors ( > https://groups.google.com/group/pylons-discuss/browse_thread/thread/54b5b3eb5e2ccfe/4e9a2abc09b9651f > ) > > As I prepare for a production release , my old code ( which i forgot > to remove ) started firing -- and I finally figured out what was > happening. > > Because I had debugging turned on via 'development.ini', Pyramid was > catching the error & response object from the app, and replacing it > with its own. > > In a perfect world, the Pyramid debug system would let the original > response/request stuff somehow persist -- so code can be written that > works on production and development. > > In a less perfect, though perfectly acceptable world, it would be > great if the debug & event subscriber docs cross-referenced one > another with an alert/note box that simply states that the debug > system will 'overtake' the response object when turned on, and > subscribers that are designed to handle errors may not work as desired > when debugging is enabled. > > -- > You received this message because you are subscribed to the Google Groups > "pylons-devel" group. > To post to this group, send email to pylons-devel@googlegroups.com. > To unsubscribe from this group, send email to > pylons-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-devel?hl=en. > -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Documentation Suggestions for Subscribers or Debug
On May 15, 7:33 pm, Michael Merickel wrote: > What? Pyramid doesn't have a "debug" code path, minus emitting some > log messages. Do you mean that the debugtoolbar is doing something to > the response? I'd imagine its either the error screens from pyramid_debugtoolbar or whatever settings like debug_templates control. pyramid.debug_templates = true pyramid.includes = pyramid_debugtoolbar when they're enabled, they seem to hijack the response object and replease it with their own -- it no longer contains any trace of the raised exception (unless you regex the debug screen html) -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
Re: Documentation Suggestions for Subscribers or Debug
I'll need to see an example. I can't think of anything except an exception view that can replace the response object. Even the toolbar only mutates the body of the response. On Tue, May 15, 2012 at 9:43 PM, Jonathan Vanasco wrote: > > > On May 15, 7:33 pm, Michael Merickel wrote: >> What? Pyramid doesn't have a "debug" code path, minus emitting some >> log messages. Do you mean that the debugtoolbar is doing something to >> the response? > > I'd imagine its either the error screens from pyramid_debugtoolbar or > whatever settings like debug_templates control. > > pyramid.debug_templates = true > pyramid.includes = pyramid_debugtoolbar > > when they're enabled, they seem to hijack the response object and > replease it with their own -- it no longer contains any trace of the > raised exception (unless you regex the debug screen html) > > -- > You received this message because you are subscribed to the Google Groups > "pylons-devel" group. > To post to this group, send email to pylons-devel@googlegroups.com. > To unsubscribe from this group, send email to > pylons-devel+unsubscr...@googlegroups.com. > For more options, visit this group at > http://groups.google.com/group/pylons-devel?hl=en. > -- You received this message because you are subscribed to the Google Groups "pylons-devel" group. To post to this group, send email to pylons-devel@googlegroups.com. To unsubscribe from this group, send email to pylons-devel+unsubscr...@googlegroups.com. For more options, visit this group at http://groups.google.com/group/pylons-devel?hl=en.
