Well its getting closer. If I use this For object in context.myscript Try: Context.myscript2 Except: Try: Print error except NameError, e: print e return e I catch the 'print error' error (because it is not defined) NOT the original try error. If I use for object in context.myscript: try: context.myscript2 except NameError, e: print e return printed it does not catch the error at all and brings up the default zope error message. If I use for object in context.myscript: try: context.myscript2 except: print 'an error has happoned' return printed I get the behaviour I want but without the error description :) Thank you all for your help so far. -----Original Message----- From: Dan Pierson [mailto:dan@control.com] Sent: Friday, 5 December 2003 1:21 PM To: Tim Zegir Subject: RE: [Zope] Another Python Script Question Look in a Python manual :-) The try statement is as follows: try: something except <exception type>, <var to hold exception info>: exception handling code E.G.: try: print error except NameError, e: print e Which will print the error you just got... Unfortunately, except without an exception type doesn't let you get info on the exception. This isn't really too bad because you should use "naked excepts" VERY rarely -- usually at the top level of a UI, because they are likely to catch things you really didn't want to catch. You should usually understand what the expected exception types are and catch them explicitly. On Thu, 2003-12-04 at 20:42, Tim Zegir wrote:
Yes it works.... sort of I now get this error
Error Type: NameError Error Value: global name 'error' is not defined
So I guess error is not the right object to use??
-----Original Message----- From: James Davies [mailto:jamesd@mena.org.au] Sent: Friday, 5 December 2003 12:12 PM To: Tim Zegir; zope@zope.org Subject: Re: [Zope] Another Python Script Question
for item in object: try: context.somescript() except: print error return printed
On Fri, 5 Dec 2003 10:51 am, Tim Zegir wrote:
How would I go about using a statement like 'on-error' in a python script? Eg. For item in object: context.somescript on-error: print error skip return printed
Thanks Tim Zegir
_______________________________________________ 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 ) -- Dan Pierson <dan@control.com>
On Thu, 2003-12-04 at 18:44, Tim Zegir wrote: [much snipping]
Thank you all for your help so far.
I'm going to go ahead and do the classic usenet thing here and not answer your question. Your basic problem is, your question is wrong. Proper error handling is the least of your concerns at this point. Since you're just getting started in Python, don't worry about how to handle errors within error handlers. That is not important. What *is* important is understanding why your code isn't correct and learning how to fix those problems. Python uses some well-worn idioms for this kind of stuff that are worth knowing about. The more you use them, the better you'll program. First off, there is almost never any good reason to call something and handle the case that it's not there. The more Pythonic way is to iterate over a collection of things that *are* there. Ex: ---- for obj in context.objectValues('Folder'): print obj.getId() return printed ---- There is no need to figure out what you do about unresolved names because you start with the set of names you want to work with. If no objects match your criteria, you'll do zero iterations. This idiom has almost no special cases... for the most part, it just works. Or let's say some group of objects have an attribute called foo and some don't. Rather than handle failure cases, you can avoid them completely: ---- for obj in context.objectValues(): if hasattr(obj, 'foo'): print obj.foo return printed ---- There's no need to break flow and go to some error-handling code like you might do in VB. If it won't work, don't do it. Python provides some very sophisticated tools for examining objects. Use 'em. There is also school of thought in Python that "it is easier to ask forgiveness than permission". In other words, go ahead and do what you're going to do, but skip the predictable failure cases. This idiom is most often used in the cases where different objects may support similar interfaces. Instead of checking object type, you can just *try* using the interface you expect, ex: ---- for obj in context.objectValues() try: print obj.foo() except: pass return printed ---- As you get into Python, I'd encourage you to read Alex Martelli's Python in a Nutshell and the O'Reilly Python Cookbook. These are indispensable references to good Python style. I know that doesn't answer your question, exactly... but hope it helps anyway. Dylan
Yes that does help, I am a VB programmer just starting to use python and zope and I am still adjusting to the "python" way of thinking. I would never have thought to do it that way. It is interesting to note that when I write a VB app now I think in a more "python" way and my programs seem better to read (to me anyway) :) So anyway yes anything helps and thank you all for you help. From Tim Zegir -----Original Message----- From: Dylan Reinhardt [mailto:zope@dylanreinhardt.com] Sent: Friday, 5 December 2003 3:29 PM To: Tim Zegir Cc: Zope Users Subject: RE: [Zope] Another Python Script Question On Thu, 2003-12-04 at 18:44, Tim Zegir wrote: [much snipping]
Thank you all for your help so far.
I'm going to go ahead and do the classic usenet thing here and not answer your question. Your basic problem is, your question is wrong. Proper error handling is the least of your concerns at this point. Since you're just getting started in Python, don't worry about how to handle errors within error handlers. That is not important. What *is* important is understanding why your code isn't correct and learning how to fix those problems. Python uses some well-worn idioms for this kind of stuff that are worth knowing about. The more you use them, the better you'll program. First off, there is almost never any good reason to call something and handle the case that it's not there. The more Pythonic way is to iterate over a collection of things that *are* there. Ex: ---- for obj in context.objectValues('Folder'): print obj.getId() return printed ---- There is no need to figure out what you do about unresolved names because you start with the set of names you want to work with. If no objects match your criteria, you'll do zero iterations. This idiom has almost no special cases... for the most part, it just works. Or let's say some group of objects have an attribute called foo and some don't. Rather than handle failure cases, you can avoid them completely: ---- for obj in context.objectValues(): if hasattr(obj, 'foo'): print obj.foo return printed ---- There's no need to break flow and go to some error-handling code like you might do in VB. If it won't work, don't do it. Python provides some very sophisticated tools for examining objects. Use 'em. There is also school of thought in Python that "it is easier to ask forgiveness than permission". In other words, go ahead and do what you're going to do, but skip the predictable failure cases. This idiom is most often used in the cases where different objects may support similar interfaces. Instead of checking object type, you can just *try* using the interface you expect, ex: ---- for obj in context.objectValues() try: print obj.foo() except: pass return printed ---- As you get into Python, I'd encourage you to read Alex Martelli's Python in a Nutshell and the O'Reilly Python Cookbook. These are indispensable references to good Python style. I know that doesn't answer your question, exactly... but hope it helps anyway. Dylan
On Thu, Dec 04, 2003 at 08:29:20PM -0800, Dylan Reinhardt wrote:
This idiom is most often used in the cases where different objects may support similar interfaces. Instead of checking object type, you can just *try* using the interface you expect, ex:
---- for obj in context.objectValues() try: print obj.foo() except: pass return printed ----
Hey now, let's not get the guy started off with bare excepts. It's generally better to catch only the exceptions you anticipate. for obj in context.objectValues() try: print obj.foo() except AttributeError: pass return printed You don't want your script to hide UnexpectedDisastrousExceptionThatRuinsEverything ;-) This is also discussed in the "easier-to-ask-forgiveness-than-permission" section of the python cookbook. -- Paul Winkler http://www.slinkp.com Look! Up in the sky! It's RASPUTIN HYPE GUNDAM! (random hero from isometric.spaceninja.com)
On Fri, 2003-12-05 at 07:27, Paul Winkler wrote:
On Thu, Dec 04, 2003 at 08:29:20PM -0800, Dylan Reinhardt wrote:
This idiom is most often used in the cases where different objects may support similar interfaces. Instead of checking object type, you can just *try* using the interface you expect, ex:
---- for obj in context.objectValues() try: print obj.foo() except: pass return printed ----
Hey now, let's not get the guy started off with bare excepts. It's generally better to catch only the exceptions you anticipate.
I'm firmly in the look-before-you-leap camp, so I won't argue that one. That said, there are other potential problems besides AttributeError to worry about. The name may be present, but you may have the wrong arguments or arguments of the wrong type, or it may be a non-callable attribute, etc. The idiom becomes vastly less useful when you have to think up four or five different problems to permit and then question what else might be lurking in those failures. I only brought it up because it *is* an idiom in Python. But I did put the (IMO) better solution first. :-) Dylan
I ended up using, --- for object in context.objectValues() try: context.myscript(foo=object.foo) except: print object.id return printed --- To find the objects that were producing these errors and fixing them manually :) Thank you all for your help From Tim Zegir 'Wisdom comes to those who are wise' -----Original Message----- From: zope-bounces@zope.org [mailto:zope-bounces@zope.org] On Behalf Of Dylan Reinhardt Sent: Saturday, 6 December 2003 2:39 AM To: Paul Winkler Cc: Zope Users Subject: Re: [Zope] Another Python Script Question On Fri, 2003-12-05 at 07:27, Paul Winkler wrote:
On Thu, Dec 04, 2003 at 08:29:20PM -0800, Dylan Reinhardt wrote:
This idiom is most often used in the cases where different objects may support similar interfaces. Instead of checking object type, you can just *try* using the interface you expect, ex:
---- for obj in context.objectValues() try: print obj.foo() except: pass return printed ----
Hey now, let's not get the guy started off with bare excepts. It's generally better to catch only the exceptions you anticipate.
I'm firmly in the look-before-you-leap camp, so I won't argue that one. That said, there are other potential problems besides AttributeError to worry about. The name may be present, but you may have the wrong arguments or arguments of the wrong type, or it may be a non-callable attribute, etc. The idiom becomes vastly less useful when you have to think up four or five different problems to permit and then question what else might be lurking in those failures. I only brought it up because it *is* an idiom in Python. But I did put the (IMO) better solution first. :-) Dylan _______________________________________________ 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 )
participants (3)
-
Dylan Reinhardt -
Paul Winkler -
Tim Zegir