We have a pylons application, running under mod-python and it talks to MySQL.
Now we have seen some strange behavior when catching the ProgrammingError
exception.
Some details about the issue. In the pylons controller we are importing
_mysql_exceptions, and we have some code that looks something like:
import _mysql_exceptions
try:
do_some_stuff()
except _mysql_exceptions.ProgrammingError, e:
handle_error()
where do_some_stuff() is in another file, which uses a custom built ORM
which has connection pooling and all the nice stuff. Therefore MySQLdb module
is imported early on in the pylons application and stays around for requests
to come. The modpython is setup to restart the application every X
requests.
Now the issue we are seeing is that the error handling code is catching the
ProgrammingError raised by code in do_some_stuff()but not always.
Initially as the application starts the exception is caught, but after T
time since the app was started, the error was no longer being caught
consistently.
the relationship between T and the nnumber of requests and X is
unknown and also the minimum T is also not known, but the effect is
consistent in our application.
log.debug('Class is same: %s', _mysql_exceptions.ProgrammingError is
MySQLdb.ProgrammingError)
With these changes the handle_error() is always called when a
ProgrammingError is raised by the mysql code. Whats strange, is that when the
number of time is < T the above debug statements print True. Where
as after the breakage point time > T, the statements prints a mix of False and True, but mainly False. The first statement printing the
name of the class, always prints _mysql_exceptions.ProgrammingError.
Has anyone faced anything like this? Does anybody know what was happening, or
have any guesses? Anybody know whats the right way to catch MySQLdb
exceptions, is it to use MySQLdb.<exc_class> or is importing
_mysql_exceptions a normal thing to do?
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
The intention is that you should only need to import MySQLdb. The
_mysql_exceptions library is named with the leading underscore to hint that
it is used internally only.
If you have a specific problem that happens when using MySQLdb.SomeException only, feel free to write a bug report. I'm puzzled by your claim that the
isinstance() result changes over time. That is curious.
If you would like to refer to this comment somewhere else in this project, copy and paste the following link:
We have a pylons application, running under mod-python and it talks to MySQL.
Now we have seen some strange behavior when catching the ProgrammingError
exception.
Some details about the issue. In the pylons controller we are importing
_mysql_exceptions, and we have some code that looks something like:
import _mysql_exceptions
try:
do_some_stuff()
except _mysql_exceptions.ProgrammingError, e:
handle_error()
where do_some_stuff() is in another file, which uses a custom built ORM
which has connection pooling and all the nice stuff. Therefore MySQLdb module
is imported early on in the pylons application and stays around for requests
to come. The modpython is setup to restart the application every X
requests.
Now the issue we are seeing is that the error handling code is catching the
ProgrammingError raised by code in do_some_stuff() but not always.
Initially as the application starts the exception is caught, but after T
time since the app was started, the error was no longer being caught
consistently.
the relationship between T and the nnumber of requests and X is
unknown and also the minimum T is also not known, but the effect is
consistent in our application.
However, changing the above block to:
import MySQLdb
try:
do_some_stuff()
except MySQLdb.ProgrammingError, e:
handle_error()
log.debug( 'Class: %s', e.class)
log.debug('isinstance: %s', isinstance(e, _mysql_exceptions.ProgrammingError))
log.debug('Class is same: %s', _mysql_exceptions.ProgrammingError is
MySQLdb.ProgrammingError)
With these changes the handle_error() is always called when a
ProgrammingError is raised by the mysql code. Whats strange, is that when the
number of time is < T the above debug statements print True. Where
as after the breakage point time > T, the statements prints a mix of
False and True, but mainly False. The first statement printing the
name of the class, always prints _mysql_exceptions.ProgrammingError.
Has anyone faced anything like this? Does anybody know what was happening, or
have any guesses? Anybody know whats the right way to catch MySQLdb
exceptions, is it to use MySQLdb.<exc_class> or is importing
_mysql_exceptions a normal thing to do?
The intention is that you should only need to import MySQLdb. The
_mysql_exceptions library is named with the leading underscore to hint that
it is used internally only.
If you have a specific problem that happens when using MySQLdb.SomeException
only, feel free to write a bug report. I'm puzzled by your claim that the
isinstance() result changes over time. That is curious.