Thanks Warren, very good advice as always.
Linux user #458601 - http://counter.li.org.
Warren Young wrote:
> Simon Pickles wrote:
>> What is the cause of a "lock failed" mysqlpp exception,
> It means you're overlapping uses of either Connection or Query in a
> way that would cause run-time failures if the library didn't catch it
> Be warned, we no longer bother catching such errors in v3.
>> what is the best approach for dealing with it?
> Pretty much the same as the advice for using MySQL++ safely in a
> multithreaded program:
> If your program already *is* multithreaded, so much the more important
> that you follow the user manual's advice.
>> template <class Type> void Select( std::vector<Type>& results,
>> const std::string& table, const std::string& where = "" )
>> m_sql = "SELECT * FROM ";
> I'm guessing m_sql is a member variable of some class? Why is it not
> just a local variable to this function? This kind of loose data
> visibility is the sort of thing that leads to the problem you're
>> catch (const mysqlpp::Exception& er)
>> // Catch-all for any other MySQL++ exceptions
>> if ( strcmp( er.what(), "lock failed" ) == 0 )
>> g_log->ERROR("Database Error: %s... retrying\n",
>> er.what() );
> It would be far better to just catch LockFailed here.
> Testing exceptions based on the text of what() makes your code
> vulnerable to failures you can only catch at run time after upgrading
> MySQL++, if we change one of the error message strings. Besides, the
> code to catch the correct exception would probably run faster than
> this strcmp stuff on the generic exception.