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