MySQL client program 2-Increase error checking

6.3 Client program 2-Increase error checking
Our second client program will be like the first client program, but will modify them to consider the possibility of error occurrence. Projects such as "practice error checking as a reader" are fairly common in the programming literature, perhaps because checking bugs is rather annoying. However, I agree with the view that the MySQL client program should test the error condition
and respond appropriately. For some reason, the call to the client library that returns the status value does these things, and you assume the consequences of ignoring them. You end up trying to catch bugs that appear in your program because there is no error checking, and users of these programs are surprised that the program is running so erratically. Consider our program, client program 1. How do I know if it's really connected to the server? You can find the Connect and quit events that correspond to the running program time by looking at the server's logs:

This message indicates that no connection was created at all. Unfortunately, client program 1 does not tell us the results that appear. Actually, it can't. It does not implement any error checking, so it doesn't even know what's happening to you. In any case, of course you don't have to look at the logs to see if you can connect to the server! Let's correct it right away. The routines that return values in the MySQL client library are basically either successful or unsuccessful in one of the following two ways:
On success, the value's pointer function returns a non-null pointer, which returns NULL when it fails (where null means "C null pointer" rather than "mysqlnull column value"). To date, the client library routines that we use Mysql_init () and Mysql_real_connect () represent success with pointers that return connection handlers, and NULL indicates failure.
The function of an integer value generally succeeds in returning 0, and the failure returns non-0. Do not test for a specific non-0 value, such as-1. Because when the failure occurs, the client library function is not guaranteed to return any particular value. Sometimes, you may see the older code that tests the return value like the following:

This test may or may not work. MYSQLAPI does not specify any non-0 error returns as a specific value, but only whether it (obviously) is 0. This test should be written in one of the following two paragraphs:

Or as shown below:

The two tests are equivalent. If you audit the source code for MySQL, you can see that it is basically tested in the first form, because it is shorter to write.
Not every API call returns a value. Another client routine we use Mysql_close () does not return a value (how does it fail?). What if it fails? In any case, connect).
Two calls in the API are useful when the client library call fails and you need detailed information about the failure. Mysql_error () returns a string containing the error message, while Mysql_errno () returns the numeric code. They should be called immediately after the error occurs, because if another API call to return status is published, any error information obtained from mysql_error () or Mysql_errno () will come from the subsequent call.
In general, it is more instructive for the user of the program to view the error string than to view the error code. If only one of the two is reported, the report string is recommended. For overall consideration, this sample of this chapter reports two values. Considering the foregoing discussion, we will write a second client program, the client program 2. It is similar to the client program
1, but the error-checking code is added appropriately. The source file client2.c looks like this:


The logic of this error check is that if it fails, both mysql_init () and mysql_real_connect () return null. Note that although this program checks the value returned by Mysql_init (), if it fails, the error reporting function is not invoked. This is because when Mysql_init () fails, it is not assumed that the connection handler includes any meaningful information.
Conversely, if Mysql_real_connect () fails, the connection handler does not reflect a valid connection, but it does include an error message that is passed to the Error reporting function (do not pass the handler to any other client routine!). Because they are generally assumed to be a valid connection, your program may crash. Compile and connect client program 2, and then try to run it:
% Client2
If the client program 2 does not have output, the connection succeeds. On the other hand, you might see the following:

This output indicates that no connection has been created, and explains why. Alternatively, it indicates that our first program, client program 1, did not successfully connect to the server (after all, client program 1 uses the same connection parameters)! And at that time we didn't know because the client program 1 did not have error checking. The client program 2 does a check, so it tells us when something goes wrong. This is why the API function return value should always be tested.
MySQL mailing list issues are often related to error checking. The typical question is "Why did my program crash when I sent this query?" "or" How did my program not return anything? "In many cases, before the query is published, the questionable program does not check whether the connection was successfully established before the query was published, or does not check the
Ensure that the server successfully executes the query before the result of the cable. Do not assume that each client library is successfully invoked.
The following example in this chapter completes the error checking, and it should be the case. It seems to have more work to do, but in the long run it is actually less work because you spend less time capturing the intricacies of the problem. This error-checking method is also used in the 7th chapter, "Perl DBI API" and chapter 8th "PHP API".
Now, when you run the Client 2 program, suppose you see a message that denies access (access denied). How can we correct this problem? One possibility is to change the #define line of the host name, user name, and password to a value that allows access to the server. This is good, in this sense, should at least be able to do a connection. However, these values are fixed encodings in the program. Therefore, I suggest not to use this method, especially the password value. When compiling your own program into binary format, you may think that the password is hidden, but if someone runs strings on a program, it simply hides (not to mention that the person who reads the source file does not have to do a little work to get the password).
We will address the problem of access in the "client program 4-Get connection parameters at run Time" section. First of all, the author
Want to explain some other ways to write your connection code.