Ooooh...... I like that. I may think of that idea myself! Good job. -- Joe
On Tuesday, September 13, 2016 at 6:33:54 AM UTC-7, tim.n...@conted.ox.ac.uk wrote: > > It may be a bad move, but I defined IntegrityError in a model, so it can > be nice and terse everywhere else: > IntegrityError = idb._adapter.driver.IntegrityError > > Where I have two different databases, I just added it to the database > objects: > db.IntegrityError = db._adapter.driver.IntegrityError > idb.IntegrityError = idb._adapter.driver.IntegrityError > > Allows for nice readable except statements > > > On Wednesday, 7 September 2016 20:47:48 UTC+1, Anthony wrote: >> >> According to the Python DB API specification, there should be a common >> set of exceptions <https://www.python.org/dev/peps/pep-0249/#exceptions>, >> and they should be exposed as attributes on the connection object >> <https://www.python.org/dev/peps/pep-0249/#connection-error>. Therefore, >> you should be able to do something like: >> >> try: >> db.mytable.insert(**fields) >> except (db._adapter.driver.IntegrityError, db._adapter.driver. >> OperationalError) as e: >> pass >> >> The above should catch the IntegrityError and OperationalError of any DB >> API compliant driver. >> >> Also, when making inserts or updates, if you don't care about the >> specific exception but just want to catch any database errors, the DAL API >> includes the following: >> >> db.mytable._on_insert_error = my_insert_error_handler >> db.mytable._on_update_error = my_update_error_handler >> >> >> Anthony >> >> On Wednesday, September 7, 2016 at 1:14:54 PM UTC-4, Joe Barnhart wrote: >>> >>> So my website runs under PostgresSQL today but will likely be switched >>> to MySql at some point in the future. My problem isn't with the DAL -- it >>> performs fine for what it does, insulating me very well from the nuances of >>> the SQL syntax for each engine. >>> >>> No, my problem comes from Exceptions. Each database engine defines its >>> own Exceptions within its driver. Even different drivers for the same >>> database engine (psycopg2 vs pg8000) come with different Exception trees. >>> If I want to be able to handle database exceptions (and who doesn't?) how >>> do I load and use the RIGHT set of Exceptions for each driver? >>> >>> When using the pg8000 driver for example, the Exceptions raised are all >>> of the form: "gluon.contrib.pg8000.ProgrammingError" or some such. Errors >>> from psycopg2 and the mysql drivers are similarly formed. I can't even use >>> this in a try-except block unless I first import gluon.contrib.pg8000. The >>> same is true for exceptions from all other database engines. >>> >>> Should we "alias" these database errors into a consistent tree inside >>> web2py? If we created a database exception tree inside web2py, and then >>> added to the database driver module a section that raised the corresponding >>> web2py Exception whenever a database exception was triggered, then we could >>> just catch ProgrammingError (from web2py) instead of >>> gluon.contrib.pg8000.ProgrammingError. >>> >>> Or, should I just put somewhere in the db definition of the models a >>> line like "import gluon.contrib.pg8000 as mydb" and then use >>> "mydb.ProgrammingError" throughout my code? I suppose I'd need to repeat >>> this in every module I create, and I create a LOT of modules.... >>> >>> Anyway, is this a real problem or am I missing something obvious?? >>> >>> -- Joe >>> >>> -- Resources: - http://web2py.com - http://web2py.com/book (Documentation) - http://github.com/web2py/web2py (Source code) - https://code.google.com/p/web2py/issues/list (Report Issues) --- You received this message because you are subscribed to the Google Groups "web2py-users" group. To unsubscribe from this group and stop receiving emails from it, send an email to web2py+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
