On 6/3/2014 04:01, Quentin Armitage wrote:
> On Sun, 2014-06-01 at 04:12 -0600, Warren Young wrote:
>> I think the explicit checks are the problem, rather than the inverse.
> My initial reaction was to agree with this, but on reflection I think it
> is helpful to have the checks. When developing code, occasionally I have
> a bug where I attempt to execute a query on a closed connection, and the
> application then coredumps
I think you've jumped over a step.
You do need to find and fix the cause of the core dump, but changing how
MySQL++ works for everyone else who uses it is not the answer.
I suspect you have MySQL++ configured to throw exceptions and you are
not catching them. Opening the core file in gdb will tell you this.
Another case that ultimately is a bug in your code, rather than in
MySQL++, is that you execute a query, it returns an error because the
connection dropped, then you try to make another without reestablishing
the connection. (Incidentally, are you aware of ReconnectOption?)
It is possible that it is MySQL++ itself core dumping, and we can fix it
in an intelligent way.
Simply checking the Connection.is_connected_ flag before executing a
query will not fix the broad "there is no connection and we tried to
execute a query" error class. It's a race condition window big enough
to fly a 747 through without making the air traffic controller nervous.
Bottom line: debug it, get some stack traces, and let's talk about