From: Warren Young
Date: January 13 2010 4:13pm
Subject: Re: Query::execute crashes without a connected driver
List-Archive: http://lists.mysql.com/plusplus/8868
Message-Id: <4B4DF136.70009@etr-usa.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

On 1/13/2010 8:16 AM, Joel Fielder wrote:
>
> But, what to do about things like affected_rows and insert_id which
> return 0 if not connected but could be considered exceptional?

I confess, I'm rather apathetic about this whole thing.  I like the "if 
you lie to the computer, it will take vengeance upon you" philosophy.

But since I *don't* care greatly, you're welcome to make these methods 
throw if throw_exceptions() == true.  They should continue to lie to the 
user if that flag isn't set.

> Also Query::escape_string(char*...) attempts the connected path when not
> connected so presumably this needs a check too?

I think you're misreading that.  If there is no conn, it should call 
DBDriver::escape_string_no_conn(), which as its name says, doesn't 
require a connection.

This code path does get exercised: there is at least one way to make 
MySQL++ SQL-escape a string where it has no access to your Connection 
object, so it has to use the C API that doesn't require a connection.  I 
don't recall off the top of my head which code path this is, but it's 
not uncommon.  I added that DBDriver method specifically to handle that 
common case.

> Is there a bigger issue of "programmer's responsibility" here?

That, but also "fail early".

I don't mind if MySQL++ lies to the programmer when the programmer lies 
to MySQL++ first.  But, if it does this, it mustn't lie in a way that 
can mask the error.

For instance, say there's a function that normally returns a pointer to 
a C string and it's not allowed to throw an exception on error.  It 
would be better in that error case to signal errors by returning a null 
pointer than "", since that will crash the program, pointing the 
debugger right at the problem line.  Returning a usable value means, at 
best, that you have to unwind the stack trace to find the problem line, 
and may mean the program can run so far past the problem line that a 
debugger is all but useless.

The empty string alternative has a secondary weakness, that an empty 
string may be a legal return value in non-error cases, so it's 
potentially ambiguous.

This may mean affected_rows() should return -1 if !throw_exceptions(), 
but that scares me a bit.  It could spell disaster if someone uses that 
like for (int i = 0; i < q.affected_rows(); ++i) ...