(Ведь clienti использует те же параметры подключения.) Об этом ничего не было известно, так как программа clienti не заботилась о проверке ошибок. Программа client2 делает такую поверку, поэтому она может сказать, когда что-то происходит не так. Вот почему всегда надо проверять значения, возврашаемые функциями программного интерфейса.

Ответы на многие вопросы можно найти при проверке ошибок. Вот типичные вопросы; почему моя профамма всегда сбоит при выдаче SQL-запроса или почему мои запросы ничего не возврашают. Во многих случаях программа, о которой идет речь, не проверяет, было ли до генерирования запроса вообше установлено соединение или был ли завершен успешно запрос. Не допускайте такой ошибочной практики, когда априори считается, что каждое обращение к клиентской библиотеке происходит успешно.

Все остальные примеры из этой главы обязательно производят проверку на ошибки, и вы, как разработчик аналогичных профамм, тоже обязаны делать это. Это может показаться сложным, но, в конечном счете это сокращает время разработки профаммного обеспечения. Аналогичный подход приводится в последующих главах 7, Профаммный интерфейс Perl API , и 8, Интерфейс API для языка написания сценариев РНР .

Теперь предположим, что офаботка профаммы client2 завершилась сообщением Access denied ( В доступе отказано ). Каким образом решить эту проблему? Можно, например, внести изменения в сфоки #def те, указав там в качестве имен сервера, пользователя и пароля такие, которые позволят осуществить достутт к серверу. Это может помочь хотя бы в том, что появится возможность подключения к серверу. Но в этом случае эти значения жестко прописаны в профаммном коде. Я не рекомендую пользоваться таким подходом, особенно при указании значения пароля. Может казаться, что в этом случае пароль надежно спрятан потому, что он скомпилирован в двоичном В1ще, но это совсем не так. (Не говоря о том, что любой, кто имеет право чтения ваших исходных файлов, без особого фуда сможет узнать ваш пароль.) О проблеме доступа мы поговорим в разделе Client4 - получение парамефов соединения во время выполнения . Но сначала рассмофим другие способы написания профаммы подключения.

Clients -модульный стиль программирования

в фетьей профамме-клиенте мы сделаем код подключения к серверу и разрыва соединения модульным, запрофаммировав его в функциях do connect() И do disconnect (), ЧТО облегчит его использование дру-Шми клиентскими программами. Это альтернатива включению кода подключения в функцию mam (). Это вообще хороший прием для любого ко-

да. Старайтесь создать функцию, которая будет доступна из любой программы, а не профаммируйте функцию каждый раз заново. Если в функции будет найдена и исправлена ошибка или сделана какая-то полезная модификация, это лучше делать один раз. Это изменение будет внесено во все профаммы, используюшие данную функцию, сразу же после перекомпиляции. Кроме того, некоторые клиентские профаммы написаны таким образом, что они подключаются к серверу и отключаются от него по несколько раз за время своего выполнения. Такую клиентскую профамму значительно проше создавать и модифицировать, придерживаясь модульного стиля написания профаммного кода. Сфатегию вьщеления кода в отдельные функции можно описать следующим образом.

1. Разбить общий код на отдельные функции и поместить их в отдельный исходный файл common. с.

2. Создать файл заголовка common.h, содержащий прототипы обших процедур.

3. Включить common.h в исходные файлы профамм-клиентов, которые используют общие процедуры.

4. Скомпилируйте общий исходный текст в объектный файл.

5. Офедактируйте связи общего объектного файла и клиентской профаммы.

Создадим процедуры do connect() и do disconnect (), применив эту Сфатегию.

Вызов процедуры doconnect () заменит собой вызовы функций mysql init() И mysql real connect () И код анализа ошибки. Вызов новой функции аналогичен mysql real connect {), за исключением того, что ему не передается дескриптор соединения. Наоборот, процедура doconnect () сама размешает и инициализирует дескриптор и возвращает указатель на него после соединения. Если происходит ошибка при выполнении процедуры doconnect (), она после диагностического сообщения возвращает null . (Таким образом, любая профамма, которая после выполнения процедуры do connect () получает значение null , может без какого-либо дополнительного диагностического сообщения просто завершать свою работ>.)

Процедура dodisconnect () принимает указатель на дескриптор соединения и вызывает функцию mysqlclose ().

Вот исходный текст common. с:

#include <stdio.h> #include <mysql.h> #include common, h

MYSQL *

do connect (char *host name, char *user name, char *password, char *db name,

unsigned int port num, char *socket name, unsigned mt flags) {

MYSQL *conn; /* указатель на дескриптор соединения */

conn = mysql init (NOLL); /* размещение и инициализация

дескриптора соединения */

if (conn == NULL) {

fprintf (stderr, сбой mysql init()\n ) ; return (NULL);

if (mysql real connect (conn, host name, user name, password, db name, portnum, socketname, flags) == NULL)

fprintf (stderr,

сбой mysql real connect(): \nError %u (%s)\n , mysql errno (conn), mysql error (conn)); return (NULL); }return (conn); /* связь установлена */

void

do disconnect (MYSQL *conn) (

mysql close (conn);

common, h объявляет прототипы процедур, находяишхся в программе

common. с . MYSQL *

do connect (char *host name, char *user name, char *password, char *db narae,

unsigned int port num, char *socket name, unsigned int flags);

void

do disconnect (MYSQL *conn) ;

Для того чтобы получить доступ к общим процедурам, подключите в исходном файле common.h. Обратите внимание на то, что common, с тоже содержит common, h. В этом случае компилятор вьщает предупреждение, если объявление функций в исходном файле common.с не совпадает с объявлениями в файле заголовка. Также если будет изменена последовательность вызовов в тексте профаммы common, с без соответствующих изменений в common.h, компилятор обязательно сделает предупреждение во время перекомпилирования common.с.

Конечно, возникает резонный вопрос, зачем вообще изобретать функцию do disconnect (), которая делает так мало. Абсолютно верно, что процедура do disconnect () и функция mysql close () эквивалентны. Но давайте предположим, что когда-нибудь позднее понадобится запрофаммировать дополнительные операции по очистке памяти в момент отключения. В случае, если есть унифицированная процедура, достаточно внести изменения только в нее. Это сделать будет невозможно, если функция mysql close () вызывается непосредственно в теле главной процедуры.

Ранее я утверждал, что модульный стиль профаммирования очень удобен и позволяет использовать модульные процедуры в нескольких