Re: [SQLObject] Handling exceptions

2006-06-01 Thread Dan Pascu
On Thursday 01 June 2006 05:30, Jorge Vargas wrote: > >The biggest problem is to translate exceptions. One DB API driver > > raises > > OperationError when another raises IntegrityError. We need to collect > > information about what exceptions every driver raise in what > > situations. > > I do

Re: [SQLObject] Handling exceptions

2006-06-01 Thread Dan Pascu
On Thursday 01 June 2006 05:46, Jorge Vargas wrote: > On 5/31/06, Dan Pascu <[EMAIL PROTECTED]> wrote: > As an example of why most of the time you will send out the "generic" > this are mysqld error classes. > > class MySQLError(StandardError): > class Warning(Warning, MySQLError): > class Error(My

Re: [SQLObject] Handling exceptions

2006-06-01 Thread Oleg Broytmann
On Thu, Jun 01, 2006 at 12:17:27AM +0300, Dan Pascu wrote: > do you prefer to wait until > someone will implement the perfect 100% complete solution somewhere in > the unknown future? Ok, let someone implements 60% soultion. Oleg. -- Oleg Broytmannhttp://phd.pp.ru/

Re: [SQLObject] Handling exceptions

2006-06-01 Thread Oleg Broytmann
On Wed, May 31, 2006 at 10:30:14PM -0400, Jorge Vargas wrote: > I believe this is what should be done, but isn't all this in pep248/249? > All exceptions and when they should be raise are there, also every exception > is a subclass of those. If only drivers follow the rules... Oleg. -- O

Re: [SQLObject] Handling exceptions

2006-05-31 Thread Jorge Vargas
On 5/31/06, Oleg Broytmann <[EMAIL PROTECTED]> wrote: On Wed, May 31, 2006 at 10:38:13PM +0300, Dan Pascu wrote:> On Wednesday 31 May 2006 21:28, Oleg Broytmann wrote:> to raise a single generic exception (say DatabaseError) with> specific details about the error, or the desire is to have a hierarc

Re: [SQLObject] Handling exceptions

2006-05-31 Thread Dan Pascu
On Wednesday 31 May 2006 23:28, Oleg Broytmann wrote: >The problem that I see with the plan is that if SQLObject starts > catching all exceptions from DB API drivers and translate them to a > single exception that would mask low-level exceptions and it would be > hard to monitor what driver rai

Re: [SQLObject] Handling exceptions

2006-05-31 Thread Oleg Broytmann
On Wed, May 31, 2006 at 10:38:13PM +0300, Dan Pascu wrote: > On Wednesday 31 May 2006 21:28, Oleg Broytmann wrote: > >There is an item in the TODO to unify exceptions. But nobody's > > working on it now. Do you want to be the one? > > What is the intention regarding this? > Is the plan Th

Re: [SQLObject] Handling exceptions

2006-05-31 Thread Dan Pascu
On Wednesday 31 May 2006 21:28, Oleg Broytmann wrote: >There is an item in the TODO to unify exceptions. But nobody's > working on it now. Do you want to be the one? What is the intention regarding this? Is the plan to raise a single generic exception (say DatabaseError) with specific detail

Re: [SQLObject] Handling exceptions

2006-05-31 Thread Dan Pascu
On Wednesday 31 May 2006 21:28, Oleg Broytmann wrote: > On Wed, May 31, 2006 at 04:06:58PM +0300, Dan Pascu wrote: > > However the code can raise exceptions from the backend (for example > > connection errors, or integrity errors when duplicate rows are > > inserted) In such a case I get exceptions

Re: [SQLObject] Handling exceptions

2006-05-31 Thread Oleg Broytmann
On Wed, May 31, 2006 at 04:06:58PM +0300, Dan Pascu wrote: > However the code can raise exceptions from the backend (for example > connection errors, or integrity errors when duplicate rows are inserted) > In such a case I get exceptions like: > > _mysql_exceptions.OperationalError > _mysql_excep

[SQLObject] Handling exceptions

2006-05-31 Thread Dan Pascu
I'm curious if there is a standard recipe on how to handle exceptions raised by the database backend modules. While I use sqlobject I obviously do not want to have to deal with specific details of the database backends. One of the reasons of using it is that it hides the database type and acce