exceptions/documentation problem
Hi, this mail is because of lack of Zope documentation. I got to call method of one of the ZopeObjects (Folder). Is there any docs about what exceptions can be thrown? Could you give me some links to it.Thanks. Regards. P.S (Disclaimer) Maybe not very best place fot this kind of post, but couldn't find better.
--On Freitag, 16. Juli 2004 13:11 Uhr +0200 Marcin Dobrzycki <marcin.dobrzycki@bmpg.pl> wrote:
Hi, this mail is because of lack of Zope documentation. I got to call method of one of the ZopeObjects (Folder). Is there any docs about what exceptions can be thrown? Could you give me some links to it.Thanks. Regards.
Try to provoke errors and see what exceptions could be thrown or look at the ObjectManager.py sources. -aj
Marcin Dobrzycki wrote at 2004-7-16 13:11 +0200:
Hi, this mail is because of lack of Zope documentation. I got to call method of one of the ZopeObjects (Folder). Is there any docs about what exceptions can be thrown? Could you give me some links to it.Thanks.
Why do you want this information? Note that it is *very* dangerous to catch exceptions. When you do, your chance is quite high that you make your persistent state inconsistent -- one of the most horrible things that can happen. Handle exceptions only in your "standard_error_message". Protocol it for your developers in precisely the form you get them ("error type", "error value" and traceback). It provides extremely valuabe information to fix problems. Convert them for your end users in crude categories based on the HTTP response code (name "status") -- 4XX codes means: dear user, you did something wrong (the "XX" classifies what the user did wrong); 5XX codes means some technical problem on the server.
P.S (Disclaimer) Maybe not very best place fot this kind of post, but couldn't find better.
This has been the correct place... -- Dieter
Dieter Maurer wrote:
Note that it is *very* dangerous to catch exceptions.
I don't think so...
When you do, your chance is quite high that you make your persistent state inconsistent -- one of the most horrible things that can happen.
Huh? try: myfolder[somevar] except KeyError: myfolder.manage_addProduct... How is that going to result in inconsistent persistent state? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote at 2004-7-19 07:55 +0100:
Dieter Maurer wrote:
Note that it is *very* dangerous to catch exceptions.
I don't think so...
When you do, your chance is quite high that you make your persistent state inconsistent -- one of the most horrible things that can happen.
Huh?
try: myfolder[somevar] except KeyError: myfolder.manage_addProduct...
How is that going to result in inconsistent persistent state?
I spoke of "your chance is quite high" and not of "you definitely will get"... The above code will not cause inconsistencies. But, whenever code in the "try" block modifies any persistent storage the chance of inconsistencies is indeed high. The danger is higher than using ZClasses ;-) -- Dieter
Dieter Maurer wrote:
But, whenever code in the "try" block modifies any persistent storage the chance of inconsistencies is indeed high.
Can you explain why? The only problem I can think of is generic except: clauses catching conflict errors. What other sources of inconsistencies are there? Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Chris Withers wrote at 2004-7-21 16:25 +0100:
Dieter Maurer wrote:
But, whenever code in the "try" block modifies any persistent storage the chance of inconsistencies is indeed high.
Can you explain why?
The only problem I can think of is generic except: clauses catching conflict errors.
What other sources of inconsistencies are there?
try: ... do something which may result in an exception of type "E" ... ... do something affecting persistent state (change in ZODB, changing an SQL database, ...) ... ... do something which may result in an exception of type "E" ... except E: ... you do not know whether or not the persistent state as been changed. When you continue without reraising an exception, the change may or may not be committed. ... ... do something affection persistent state now you may have got an inconsistency (when the first change did not happen) ... Note that many standard exceptions ("E" above) can easily be raised by code you would not immediately expect. -- Dieter
Dieter Maurer wrote:
try: ... do something which may result in an exception of type "E" ... ... do something affecting persistent state (change in ZODB, changing an SQL database, ...) ...
If these aren't transactionally aware presistent changes (such as editing a disk-absed file) then yes, I'd agree...
... do something which may result in an exception of type "E" ... except E: ... you do not know whether or not the persistent state as been changed.
If that's important ot your app, then your try/except should be made smaller ;-) If the persistent state change was to write something to an event log in SQL, then your described behaviour might be required, not just acceptable ;-)
When you continue without reraising an exception, the change may or may not be committed. ...
Well, catching an exception is program flow control. Your statement is the same as saying: if x > 10: y = -1 else: y = +1 ...means you don't knwo what the value of Y will be.
Note that many standard exceptions ("E" above) can easily be raised by code you would not immediately expect.
I'm not sure I beleive this unless you're talking about broken DA's. ZODB certainly doesn't do this... Chris -- Simplistix - Content Management, Zope & Python Consulting - http://www.simplistix.co.uk
Dieter Maurer wrote at July 16, 2004 9:36 pm:
Marcin Dobrzycki wrote at 2004-7-16 13:11 +0200:
Hi, this mail is because of lack of Zope documentation. I got to call method of one of the ZopeObjects (Folder). Is there any docs about what exceptions can be thrown? Could you give me some links to it.Thanks.
Why do you want this information?
It's my way to find out if the specified folder exists.
Note that it is *very* dangerous to catch exceptions.
Is there any better way? If so, I didn't find it. Didn't find something like folder_object.has_child('my_sub_folder') method. And listing all subobjects' id in container, and comparing each id with folder I want to add is, let's say, a little bit awkward. Thank you for RE. My regards.
Marcin Dobrzycki wrote at 2004-7-19 10:20 +0200:
Dieter Maurer wrote at July 16, 2004 9:36 pm:
Marcin Dobrzycki wrote at 2004-7-16 13:11 +0200:
Hi, this mail is because of lack of Zope documentation. I got to call method of one of the ZopeObjects (Folder). Is there any docs about what exceptions can be thrown? Could you give me some links to it.Thanks.
Why do you want this information?
It's my way to find out if the specified folder exists.
Note that it is *very* dangerous to catch exceptions.
Is there any better way? If so, I didn't find it. Didn't find something like folder_object.has_child('my_sub_folder') method. And listing all subobjects' id in container, and comparing each id with folder I want to add is, let's say, a little bit awkward.
Make a Python Script, say "has_unacquired", with parameter "attr" and the following body: return hasattr(context.aq_inner.aq_parent, attr) Use "obj.has_unacquired(attr)" whenever you want to check, whether "obj" has attribute "attr". This will work because most Zope containers expose their content as attributes. You may get "True" back also for non content attributes but usually, this is precisely what you want (you will not be able to create a content object with an id conflicting with another attribute). -- Dieter
participants (4)
-
Andreas Jung -
Chris Withers -
Dieter Maurer -
Marcin Dobrzycki