Re: [Zope-dev] Pointless exception re-raising in DA.py
Clemens Robbenhaar wrote: Ok, if this is the proper dance to catch such exceptions with Zope without risking ZODB corruption I will go with it. So far I have not been sure, that ConflictError is the only type needing special treatement in these cases. Well, the PROPER dance would be to only catch exceptions that you're happy to ignroe from your database. You should be able to find those otu fairly quickly. Any new ones htat come along later probably want to be looked at by you before being automatically ignored... Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Pointless exception re-raising in DA.py
Dieter Maurer wrote:
try: DB__=dbc()
except:
exc_type, exc_value, trc = sys.exc_info()
raise DatabaseError('%s is not connected to a database' % self.id,
exc_type,
exc_value), trc
I didn't know you could re-raise a traceback like this... where's tha tsyntax
documented?
Define DatabaseError in such a way that its __str__ includes
information about the original exception.
This seems needlessly overcomplicated to me...
Chris
--
Simplistix - Content Management, Zope Python Consulting
- http://www.simplistix.co.uk
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Pointless exception re-raising in DA.py
On Thu, Mar 25, 2004 at 10:23:27AM +, Chris Withers wrote:
Dieter Maurer wrote:
try: DB__=dbc()
except:
exc_type, exc_value, trc = sys.exc_info()
raise DatabaseError('%s is not connected to a database' % self.id,
exc_type,
exc_value), trc
I didn't know you could re-raise a traceback like this... where's tha
tsyntax documented?
In the language reference:
http://www.python.org/doc/current/ref/raise.html
See also the sys.exc_info docs in the library reference:
http://www.python.org/doc/current/lib/module-sys.html#l2h-331
-Andrew.
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Pointless exception re-raising in DA.py
Hi All, In Shared/DC/ZRDB/DA.py, Line 399 of Zope 2.6.1 and line 419 in 2.7.0, there's this rather pointless lump of code: try: DB__=dbc() except: raise DatabaseError, ( '%s is not connected to a database' % self.id) ...which only serves to mask the real cause of the problem when trying to obtain a connection. Would anyone have any objections if I changed this to simply: DB__ = dbc() ? (if no responses, I'll assume that means you agree with my proposed change ;-) Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
[Zope-dev] Pointless exception re-raising in DA.py
Hi Chris, In Shared/DC/ZRDB/DA.py, Line 399 of Zope 2.6.1 and line 419 in 2.7.0, there's this rather pointless lump of code: try: DB__=dbc() except: raise DatabaseError, ( '%s is not connected to a database' % self.id) ...which only serves to mask the real cause of the problem when trying to obtain a connection. I remeber I made a collector issue about that liens of code: http://www.zope.org/Collectors/Zope/927 Previously this has been a string valued exception. Actually I like it to be an exception of a certain type now, because I can now selectively catching this DatabaseError and distinguish it from other errors. No need for a evil bare except. The reason is that I would like to treat errors when accessing an external data base different from other errors; often the data obtained there is only optional to the page, so I don't want to show usered the error page in this case, only to fill up doem slot with sorry, that certain piece of information is not availabe, because our sql data base sucks. I see Your point. However is there any chance that dbc() does raise something more specific? I am afraid it does not. If it does not, I would have to go back to an evil bare except ... Cheers, Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Pointless exception re-raising in DA.py
Hi there, Clemens Robbenhaar wrote: I remeber I made a collector issue about that liens of code: http://www.zope.org/Collectors/Zope/927 Indeed. Catching everything and raising a string exception is evil, and I was glad to see that go. Previously this has been a string valued exception. Actually I like it to be an exception of a certain type now, because I can now selectively catching this DatabaseError and distinguish it from other errors. No need for a evil bare except. Well, I'm afraid I don't agree here... The reason is that I would like to treat errors when accessing an external data base different from other errors; often the data obtained there is only optional to the page, so I don't want to show usered the error page in this case, only to fill up doem slot with sorry, that certain piece of information is not availabe, because our sql data base sucks. ...this is an application level decision. The code currently makes it very easy, but at the expense of debugging any unexpected exceptions that code throws. While relational data may be optional for you, for many people it is ESSENTIAL, and is used for things like their auth details, content storage, etc. For them, this piece of code causes MAJOR suffering, especially for intermittent failures where you can't just insert a print_traceback and try again ;-) I see Your point. However is there any chance that dbc() does raise something more specific? I am afraid it does not. No, that's the whole point. If that code raises an exception, it's much more useful if it can be logged and dealt with in its original form rather than have it morphed into something uniform and meaningless. If it does not, I would have to go back to an evil bare except ... I wouldn't if I were you: try: *your zsql method except ConflictError: raise except Exception: return sorry, that certain piece of information is not availabe, because our sql data base sucks If your database adapter raises a string exception, THEN you have to add a bare except on the end of that, but if that's the case you should beat the DA author with a stick until he fixes it. cheers, Chris -- Simplistix - Content Management, Zope Python Consulting - http://www.simplistix.co.uk ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Pointless exception re-raising in DA.py
Hi Chris, [...] ...this is an application level decision. The code currently makes it very easy, but at the expense of debugging any unexpected exceptions that code throws. While relational data may be optional for you, for many people it is ESSENTIAL, and is used for things like their auth details, content storage, etc. For them, this piece of code causes MAJOR suffering, especially for intermittent failures where you can't just insert a print_traceback and try again ;-) Ok, understand (I guess ;-) [...] If it does not, I would have to go back to an evil bare except ... I wouldn't if I were you: try: *your zsql method except ConflictError: raise except Exception: return sorry, that certain piece of information is not availabe, because our sql data base sucks Ok, if this is the proper dance to catch such exceptions with Zope without risking ZODB corruption I will go with it. So far I have not been sure, that ConflictError is the only type needing special treatement in these cases. Clemens ___ Zope-Dev maillist - [EMAIL PROTECTED] http://mail.zope.org/mailman/listinfo/zope-dev ** No cross posts or HTML encoding! ** (Related lists - http://mail.zope.org/mailman/listinfo/zope-announce http://mail.zope.org/mailman/listinfo/zope )
Re: [Zope-dev] Pointless exception re-raising in DA.py
Chris Withers wrote at 2004-3-24 15:36 +:
...
The reason is that I would like to treat errors when accessing
an external data base different from other errors; often the data
obtained there is only optional to the page, so I don't want to show
usered the error page in this case, only to fill up doem slot with
sorry, that certain piece of information is not availabe, because our
sql data base sucks.
...this is an application level decision. The code currently makes it very easy,
but at the expense of debugging any unexpected exceptions that code throws.
You can have both!
It is just a little more work for you (I know you are lazy...):
try: DB__=dbc()
except:
exc_type, exc_value, trc = sys.exc_info()
raise DatabaseError('%s is not connected to a database' % self.id,
exc_type,
exc_value), trc
trc = None
Define DatabaseError in such a way that its __str__ includes
information about the original exception.
--
Dieter
___
Zope-Dev maillist - [EMAIL PROTECTED]
http://mail.zope.org/mailman/listinfo/zope-dev
** No cross posts or HTML encoding! **
(Related lists -
http://mail.zope.org/mailman/listinfo/zope-announce
http://mail.zope.org/mailman/listinfo/zope )
