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) ...
