Documentation Suggestions for Subscribers or Debug

2012-05-15 Thread Jonathan Vanasco
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

2012-05-15 Thread Michael Merickel
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 jonat...@findmeon.com 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.