I am using zope 2.9, python 3.4. when I have a bug in my python I get "Uncaptured Python Exception" coming from zope. This is a nightmare. I have spent hours trying to trace down the simplest typos that would have been instantly reported in any other development environment. How do I get zope to "Capture" these exceptions? I just want to know what line the error occurred in! Anything at all would be helpful! Do I need a different version of zope or python? Perhaps a python module? Jon
--On 31. Mai 2007 09:58:43 -0400 Jon Emmons <jon.emmons@earthwavetech.com> wrote:
I am using zope 2.9, python 3.4.
Python 2.4 you mean...
when I have a bug in my python I get "Uncaptured Python Exception" coming from zope.
Without the full traceback such a question is pretty much worthless. Uncaptured Python exception are usually coming from the ZServer or Medusa when a client disconnects before Zope has completed the request. Nothing to worry about-
This is a nightmare. I have spent hours trying to trace down the simplest typos that would have been instantly reported in any other development environment.
Provide the *full* traceback. -aj
----- Original Message ----- From: "Jon Emmons" <jon.emmons@earthwavetech.com> To: <zope@zope.org> Sent: Thursday, May 31, 2007 9:58 AM Subject: [Zope] Uncaptured python exception
I am using zope 2.9, python 3.4. when I have a bug in my python I get "Uncaptured Python Exception" coming from zope.
This is a nightmare. I have spent hours trying to trace down the simplest typos that would have been instantly reported in any other development environment.
How do I get zope to "Capture" these exceptions? I just want to know what line the error occurred in! Anything at all would be helpful!
Do I need a different version of zope or python? Perhaps a python module?
Zope 2.9.x requires python 2.4.2 or 2.4.3 Jonathan
Oops, my bad. Python is 2.4.4. (not 3.4) perhaps my python needs to be moved back a bit. I don't get any error in the error log from the zope admin, just this cryptic msg from the window that zope is running in. 2007-05-31 09:48:49 ERROR ZServer uncaptured python exception, closing channel <ZServer.HTTPServer.zhttp_channel connected 206.246.160.45:20916 at -0x49709f74 channel#: 202 requests:> (socket.error:(104, 'Connection reset by peer') [/usr/local/lib/python2.4/asynchat.py|initiate_send|219] [/home/zope/zope/lib/python/ZServer/medusa/http_server.py|send|417] [/usr/local/lib/python2.4/asyncore.py|send|332]) -----Original Message----- From: Jonathan [mailto:dev101@magma.ca] Sent: Thursday, May 31, 2007 10:07 AM To: Jon Emmons; zope@zope.org Subject: Re: [Zope] Uncaptured python exception ----- Original Message ----- From: "Jon Emmons" <jon.emmons@earthwavetech.com> To: <zope@zope.org> Sent: Thursday, May 31, 2007 9:58 AM Subject: [Zope] Uncaptured python exception
I am using zope 2.9, python 3.4. when I have a bug in my python I get "Uncaptured Python Exception" coming from zope.
This is a nightmare. I have spent hours trying to trace down the simplest typos that would have been instantly reported in any other development environment.
How do I get zope to "Capture" these exceptions? I just want to know what line the error occurred in! Anything at all would be helpful!
Do I need a different version of zope or python? Perhaps a python module?
Zope 2.9.x requires python 2.4.2 or 2.4.3 Jonathan
On 5/31/07, Jon Emmons <jon.emmons@earthwavetech.com> wrote:
I don't get any error in the error log from the zope admin, just this cryptic msg from the window that zope is running in.
2007-05-31 09:48:49 ERROR ZServer uncaptured python exception, closing channel <ZServer.HTTPServer.zhttp_channel connected 206.246.160.45:20916 at -0x49709f74 channel#: 202 requests:> (socket.error:(104, 'Connection reset by peer') [/usr/local/lib/python2.4/asynchat.py|initiate_send|219] [/home/zope/zope/lib/python/ZServer/medusa/http_server.py|send|417] [/usr/local/lib/python2.4/asyncore.py|send|332])
This just means that the browser disconnected before the request was completely sent. In other words, the user used the Stop button. Nothing to worry about. -- Martijn Pieters
--On 31. Mai 2007 10:12:35 -0400 Jon Emmons <jon.emmons@earthwavetech.com> wrote:
Oops, my bad.
Python is 2.4.4. (not 3.4) perhaps my python needs to be moved back a bit.
I don't get any error in the error log from the zope admin, just this cryptic msg from the window that zope is running in.
2007-05-31 09:48:49 ERROR ZServer uncaptured python exception, closing channel <ZServer.HTTPServer.zhttp_channel connected 206.246.160.45:20916 at -0x49709f74 channel#: 202 requests:> (socket.error:(104, 'Connection reset by peer') [/usr/local/lib/python2.4/asynchat.py|initiate_send|219] [/home/zope/zope/lib/python/ZServer/medusa/http_server.py|send|417] [/usr/local/lib/python2.4/asyncore.py|send|332])
This indicates that the client closed the connection before completing the request. Not a Zope issue - it's in fact no issue. -aj
Thanks all for your help. I guess I was worried about nothing. Previous versions of zope did not generate those messages. I thought it was why I was getting no zope error at all with runtime errors. I still don't know why python errors will just quietly cause things to fail with no zope error at all. Nothing... That may be something I just have to live with. Very difficult to debug and develop with though. Syntax errors I can find by simply importing the external method into the python interpreter. But dealing with the form variables, I will often have runtime errors that give no message at all. So I find myself putting little "I am here" print messaged throughout my code to try to zone in on where I mistyped the variable equipment_num as equipment_mun. Jon -----Original Message----- From: Andreas Jung [mailto:lists@zopyx.com] Sent: Thursday, May 31, 2007 10:25 AM To: Jon Emmons; 'Jonathan'; zope@zope.org Subject: RE: [Zope] Uncaptured python exception --On 31. Mai 2007 10:12:35 -0400 Jon Emmons <jon.emmons@earthwavetech.com> wrote:
Oops, my bad.
Python is 2.4.4. (not 3.4) perhaps my python needs to be moved back a bit.
I don't get any error in the error log from the zope admin, just this cryptic msg from the window that zope is running in.
2007-05-31 09:48:49 ERROR ZServer uncaptured python exception, closing channel <ZServer.HTTPServer.zhttp_channel connected 206.246.160.45:20916 at -0x49709f74 channel#: 202 requests:> (socket.error:(104, 'Connection reset by peer') [/usr/local/lib/python2.4/asynchat.py|initiate_send|219] [/home/zope/zope/lib/python/ZServer/medusa/http_server.py|send|417] [/usr/local/lib/python2.4/asyncore.py|send|332])
This indicates that the client closed the connection before completing the request. Not a Zope issue - it's in fact no issue. -aj
--On 31. Mai 2007 11:06:17 -0400 Jon Emmons <jon.emmons@earthwavetech.com> wrote:
Thanks all for your help.
I guess I was worried about nothing. Previous versions of zope did not generate those messages.
Nonsense. Such error messages are shown by Zope since ages.
I thought it was why I was getting no zope error at all with runtime errors.
I still don't know why python errors will just quietly cause things to fail with no zope error at all. Nothing... That may be something I just have to live with. Very difficult to debug and develop with though.
What's the point? There is nothing to worry about. Your client closes the connection and Zope reacts with throwing an exception. There is nothing else Zope could do - either you catch the exception and swallow it or it won't catch the exception...so what's your *real* problem with the behavior? -aj
----- Original Message ----- From: "Jon Emmons" <jon.emmons@earthwavetech.com> To: "'Andreas Jung'" <lists@zopyx.com>; "'Jonathan'" <dev101@magma.ca>; <zope@zope.org> Sent: Thursday, May 31, 2007 11:06 AM Subject: RE: [Zope] Uncaptured python exception
I still don't know why python errors will just quietly cause things to fail with no zope error at all. Nothing... That may be something I just have to live with. Very difficult to debug and develop with though.
Syntax errors I can find by simply importing the external method into the python interpreter.
Syntax errors for external methods can also be found by clicking on the 'Save Changes' button of the external method object when in the ZMI.
But dealing with the form variables, I will often have runtime errors that give no message at all.
So I find myself putting little "I am here" print messaged throughout my code to try to zone in on where I mistyped the variable equipment_num as equipment_mun.
Referring to non-existent python variables (eg. the mistyping you described above) should raise a KeyError. Do you have any try/except statements in your external method which may be capturing the errors? Jonathan
Sometimes, I do get those errors. But if I take a working piece of python and stick in a sabotage statement like: Var1 = var2 Where var2 is undefined (i.e. has never been assigned anything) Just silent failure. No error. Jon -----Original Message----- From: Jonathan [mailto:dev101@magma.ca] Sent: Thursday, May 31, 2007 11:15 AM To: Jon Emmons; zope@zope.org Subject: Re: [Zope] Uncaptured python exception ----- Original Message ----- From: "Jon Emmons" <jon.emmons@earthwavetech.com> To: "'Andreas Jung'" <lists@zopyx.com>; "'Jonathan'" <dev101@magma.ca>; <zope@zope.org> Sent: Thursday, May 31, 2007 11:06 AM Subject: RE: [Zope] Uncaptured python exception
I still don't know why python errors will just quietly cause things to fail with no zope error at all. Nothing... That may be something I just have to live with. Very difficult to debug and develop with though.
Syntax errors I can find by simply importing the external method into the python interpreter.
Syntax errors for external methods can also be found by clicking on the 'Save Changes' button of the external method object when in the ZMI.
But dealing with the form variables, I will often have runtime errors that give no message at all.
So I find myself putting little "I am here" print messaged throughout my code to try to zone in on where I mistyped the variable equipment_num as equipment_mun.
Referring to non-existent python variables (eg. the mistyping you described above) should raise a KeyError. Do you have any try/except statements in your external method which may be capturing the errors? Jonathan
-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Emmons wrote:
Sometimes, I do get those errors.
But if I take a working piece of python and stick in a sabotage statement like:
Var1 = var2
Where var2 is undefined (i.e. has never been assigned anything)
Just silent failure. No error.
Sorry, but without a full recipe to reproduce this, I don't believe you; Zope raises exceptions just fine, and catches them itself only at the publisher layer, where they get rendered into a standard error message, as well as being dumped to the 'error_log' object. The effect you describe would only occur if some piece of application code (your script, or something that calls it) were swallowing the exception with a 'try: ... except: pass' (or similar). I would need to see the entire text of your script, plus whether this is a PythonScript, an ExternalMethod, or some bit of filesystem product code. I would also need to know what version of Zope and Python you are using. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGXvHa+gerLs4ltQ4RAu6eAJ9rAgo3ZSYT7IOkj9YP5ySuPoVFkwCfdARO M54huFuJk8+C49WTgsfk5/Y= =Av4D -----END PGP SIGNATURE-----
Ok, Your statements have just helped me A LOT! I began to look at the menu structure of our app and it goes something like this: <dtml-try> <dtml-let report="REQUEST.SESSION.get('choice')> <dtml-if expr="report == 'ReportName'"> <dtml-var report_one> </dtml-if> </dtml-let> <dtml-except> Show report menu... </dtml-try> Which would cause all exceptions to be captured and throw you back to the menu. I clearly need to restructure this piece of code. This was obscuring my python errors. My apologies, and my thanks for helping me think this out. Jon -----Original Message----- From: zope-bounces@zope.org [mailto:zope-bounces@zope.org] On Behalf Of Tres Seaver Sent: Thursday, May 31, 2007 12:04 PM To: zope@zope.org Subject: [Zope] Re: Uncaptured python exception -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Jon Emmons wrote:
Sometimes, I do get those errors.
But if I take a working piece of python and stick in a sabotage statement like:
Var1 = var2
Where var2 is undefined (i.e. has never been assigned anything)
Just silent failure. No error.
Sorry, but without a full recipe to reproduce this, I don't believe you; Zope raises exceptions just fine, and catches them itself only at the publisher layer, where they get rendered into a standard error message, as well as being dumped to the 'error_log' object. The effect you describe would only occur if some piece of application code (your script, or something that calls it) were swallowing the exception with a 'try: ... except: pass' (or similar). I would need to see the entire text of your script, plus whether this is a PythonScript, an ExternalMethod, or some bit of filesystem product code. I would also need to know what version of Zope and Python you are using. Tres. - -- =================================================================== Tres Seaver +1 540-429-0999 tseaver@palladion.com Palladion Software "Excellence by Design" http://palladion.com -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFGXvHa+gerLs4ltQ4RAu6eAJ9rAgo3ZSYT7IOkj9YP5ySuPoVFkwCfdARO M54huFuJk8+C49WTgsfk5/Y= =Av4D -----END PGP SIGNATURE----- _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
Var1 = var2
Where var2 is undefined (i.e. has never been assigned anything)
Just silent failure. No error. So how do you know there is a failure then? There is really nothing in event.log and nothing in error_log?
-- Maciej Wisniowski
The example 'var1 = var2' should cause the NameError exception. "NameError: name 'var2' is not defined" You might want to check your 'error log' objects for the error messages. If you don't have an error log object, it might be a good idea to create one. On 5/31/07, Maciej Wisniowski <maciej.wisniowski@coig.katowice.pl> wrote:
Var1 = var2
Where var2 is undefined (i.e. has never been assigned anything)
Just silent failure. No error. So how do you know there is a failure then? There is really nothing in event.log and nothing in error_log?
-- Maciej Wisniowski _______________________________________________ Zope maillist - Zope@zope.org http://mail.zope.org/mailman/listinfo/zope ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope-dev )
-- Thanks, Derek Wilson
Jon Emmons wrote at 2007-5-31 11:06 -0400:
... I still don't know why python errors will just quietly cause things to fail with no zope error at all. Nothing... That may be something I just have to live with. Very difficult to debug and develop with though.
This is a *very* unusual behaviour of Zope. I have never seen it (or heard about it before your post). I know of only a single problem where Zope does not reliably report problems: when a product cannot be imported during startup, then the only hint may be in Zope's logfile -- especially, the product may not seem to be broken in "Control_Panel --> Product management. But that is definitely not your problem.
Syntax errors I can find by simply importing the external method into the python interpreter. But dealing with the form variables, I will often have runtime errors that give no message at all.
I fear somehow you have screwed up your Zope. It behaves differently from how we know it. To be sure: you look into the "error_log" object in the ZMI, have removed any "exceptions to be ignored" and nevertheless do not see any error log messages there? -- Dieter
participants (8)
-
Andreas Jung -
Dieter Maurer -
Jon Emmons -
Jonathan -
Maciej Wisniowski -
Martijn Pieters -
SpiderX -
Tres Seaver