; 6.3 客戶機(jī)程序2—增加錯(cuò)誤檢查 ; 我們的第二個(gè)客戶機(jī)程序?qū)⑾竦谝粋€(gè)客戶機(jī)程序一樣，但是將修改它們，考慮錯(cuò)誤出現(xiàn)的可能性?！皩㈠e(cuò)誤檢查作為讀者的練習(xí)”這樣的項(xiàng)目在編程文獻(xiàn)中相當(dāng)常見，這或許是因?yàn)闄z查錯(cuò)誤相當(dāng)令人討厭。但是，我贊同這種觀點(diǎn)，即MySQL客戶機(jī)程序應(yīng)該測(cè)試錯(cuò)誤條件并適當(dāng)?shù)剡M(jìn)行回應(yīng)。由于某種原因，返回狀態(tài)值的客戶機(jī)庫(kù)的調(diào)用做這些事情，而且您要承擔(dān)忽略它們的后果。您最終還是要試圖捕獲由于沒有錯(cuò)誤檢查而出現(xiàn)在程序中的錯(cuò)誤，這些程序的用戶會(huì)對(duì)程序運(yùn)行如此不規(guī)律感到奇怪?？紤]我們的程序，客戶機(jī)程序1。如何知道它是否真正連接到服務(wù)器上？可以通過查看服務(wù)器的日志，找出與運(yùn)行程序時(shí)間相應(yīng)的Connect和Quit事件： 這條消息表示根本沒有創(chuàng)建連接。不幸的是，客戶機(jī)程序1沒有告訴我們出現(xiàn)的這些結(jié)果。實(shí)際上它不能。它不能實(shí)現(xiàn)任何錯(cuò)誤檢查，所以它甚至不知道自己發(fā)生了什么事。無(wú)論如何，當(dāng)然不一定必須查看日志來(lái)尋找是否能連接到服務(wù)器！讓我們立刻改正它。在MySQL客戶機(jī)庫(kù)中返回值的例程基本上以下列兩種方式之一表示成功或失敗： ; ■ 成功時(shí)，值的指針函數(shù)返回一個(gè)非NULL 指針，失敗時(shí)返回NULL（在這里NULL 的意思是“C NULL 指針”，而不是“MySQLNULL 列值”）。迄今為止，我們使用的客戶機(jī)庫(kù)的例程mysql_init() 和mysql_real_connect() 都用返回連接處理程序的指針來(lái)表示成功， NULL 表示失敗。 ; ■ 整型數(shù)值的函數(shù)一般成功返回0，失敗返回非0。不要測(cè)試特定的非0值，如- 1。因?yàn)楫?dāng)失敗時(shí)，并不保證客戶機(jī)庫(kù)函數(shù)返回任何特定的值。有時(shí)，您可能會(huì)看到像如下的較舊的錯(cuò)誤地測(cè)試返回值的代碼： 這個(gè)測(cè)試可能工作，也可能不工作。MySQLAPI 不將任何非0錯(cuò)誤的返回指定為特定的值，而只判斷它（顯然地）是否為0。這個(gè)測(cè)試應(yīng)該寫成下面兩段之一： 或如下所示： 這兩個(gè)測(cè)試是等價(jià)的。如果審核MySQL的源代碼，則可以發(fā)現(xiàn)，它基本上用第一種形式測(cè)試，因?yàn)檫@編寫起來(lái)更簡(jiǎn)短。 ; 不是每個(gè)API 調(diào)用都返回值。我們使用的另一個(gè)客戶機(jī)例程mysql_close() 就不返回值（它如何失敗？失敗了又如何？無(wú)論如何，都要進(jìn)行連接）。 ; 當(dāng)客戶機(jī)庫(kù)調(diào)用失敗，并且需要有關(guān)失敗的詳細(xì)信息時(shí)， API 中的兩個(gè)調(diào)用都是有用的。mysql_error() 返回包括錯(cuò)誤信息的字符串，而mysql_errno() 返回?cái)?shù)值代碼。應(yīng)該在錯(cuò)誤出現(xiàn)以后立刻調(diào)用它們，因?yàn)槿绻l(fā)布另一個(gè)返回狀態(tài)的API 調(diào)用，則從mysql_error() 或mysql_errno() 獲取的任何錯(cuò)誤信息都將來(lái)自于后面的調(diào)用。 ; 一般來(lái)說(shuō)，程序的用戶查看錯(cuò)誤字符串比查看錯(cuò)誤代碼更有啟發(fā)。如果只報(bào)告兩者中的一個(gè)，則建議報(bào)告字符串。出于全面考慮，本章的這個(gè)樣例報(bào)告兩個(gè)值。考慮前述的討論，我們將編寫第二個(gè)客戶機(jī)程序，即客戶機(jī)程序2。它類似于客戶機(jī)程序 ; 1，但是適當(dāng)?shù)卦黾恿隋e(cuò)誤檢查代碼。源文件client2.c 如下所示： 這個(gè)錯(cuò)誤檢查的邏輯是，如果失敗，則mysql_init() 和mysql_real_connect() 都返回NULL。請(qǐng)注意，盡管這個(gè)程序檢查mysql_init() 返回的值，但是，如果它失敗，卻不調(diào)用錯(cuò)誤報(bào)告函數(shù)。這是因?yàn)楫?dāng)mysql_init() 失敗時(shí)，不能假設(shè)連接處理程序包括任何有意義的信息。 ; 相反，如果mysql_real_connect() 失敗了，則連接處理程序并不反映有效的連接，但是的確包括傳送給錯(cuò)誤報(bào)告函數(shù)的錯(cuò)誤信息（不要將該處理程序傳送給任何其他的客戶機(jī)例程！因?yàn)樗鼈円话慵僭O(shè)是一個(gè)有效連接，所以您的程序可能崩潰）。編譯和連接客戶機(jī)程序2，然后試著運(yùn)行它： ;% client2 ; 如果客戶機(jī)程序2沒有別輸出，則連接成功。另一方面，可能會(huì)如下所示： 這個(gè)輸出表示沒有創(chuàng)建連接，并說(shuō)明為什么?；蛘?，它還表示我們的第一個(gè)程序，即客戶機(jī)程序1，沒有成功地連接到服務(wù)器（畢竟客戶機(jī)程序1使用同樣的連接參數(shù)）！而在那時(shí)我們不知道，因?yàn)榭蛻魴C(jī)程序1沒有錯(cuò)誤檢查。而客戶機(jī)程序2做檢查，所以當(dāng)出問題時(shí)，它可以告知我們。這就是應(yīng)該始終測(cè)試API 函數(shù)返回值的原因。 ; MySQL郵件清單問題經(jīng)常是與錯(cuò)誤檢查有關(guān)的。典型的問題是“當(dāng)發(fā)送這個(gè)查詢時(shí)，為什么我的程序崩潰了？”或“我的程序怎么沒有返回任何東西？”在許多情況下，在查詢發(fā)布以前，有疑問的程序不檢查在發(fā)布該查詢前是否成功地建立了連接，或者不檢查在試著檢索結(jié)果前確保服務(wù)器成功執(zhí)行該查詢。不要假定每個(gè)客戶機(jī)庫(kù)都調(diào)用成功。 ; 本章下面的例子完成錯(cuò)誤檢查，而且也應(yīng)該這樣?？雌饋?lái)它好像有更多的工作，但是從長(zhǎng)遠(yuǎn)地運(yùn)行來(lái)看，它的工作實(shí)際上是少的，因?yàn)槟M(fèi)了更少的時(shí)間來(lái)捕獲錯(cuò)綜復(fù)雜的問題。在第7章“Perl DBI API”和第8章“PHP API”中，也使用這種檢查錯(cuò)誤的方法。 ; 現(xiàn)在，當(dāng)運(yùn)行客戶機(jī)2的程序時(shí)，假設(shè)看到拒絕訪問（ Access denied）的消息。如何改正這個(gè)問題呢？一種可能是將主機(jī)名稱、用戶名稱和口令的#define 行更改為允許訪問服務(wù)器的值。這是有好處的，在這個(gè)意義上，至少應(yīng)該能做一個(gè)連接。但是，這些值是程序中的固定編碼。所以筆者建議不要用這種方法，特別是對(duì)口令值。當(dāng)將自己的程序編譯為二進(jìn)制格式時(shí)，您可能認(rèn)為口令隱藏起來(lái)了，但是，如果有人在程序上運(yùn)行strings，則它根本隱藏不住（更不用說(shuō)明讀取訪問源文件的人根本不用做一點(diǎn)工作，就可以獲取口令）。 ; 在“客戶機(jī)程序4—運(yùn)行時(shí)獲取連接參數(shù)”一節(jié)中我們將處理訪問的問題。首先，筆者想說(shuō)明編寫連接代碼的一些其他方法。