MySQL数据库技术(31)[MySQL防范]
本文“MySQL数据库技术(31)[MySQL防范]”是由七道奇为您精心收集,来源于网络转载,文章版权归文章作者所有,本站不对其观点以及内容做任何评价,请读者自行判断,以下是其具体内容:
? 6.3 客户机程序2—增添错误查抄
? ? 我们的第二个客户机程序将像第一个客户机程序一样,但是将改正它们,考虑错误呈现的大概性."将错误查抄作为读者的操练"这样的项目在编程文献中相当常见,这大概是因为查抄错误相当令人讨厌.但是,我赞成这种概念,即MySQL 客户机程序应当测试错误条件
并适本地举行回应.由于某种缘由,返回状况值的客户机库的调用做这些事情,并且您要承当忽视它们的后果.您终究还是要试图捕捉由于没有错误查抄而呈目前程序中的错误,这些程序的用户会对程序运行如此不规律感到奇特.考虑我们的程序,客户机程序1.若何知道它能否真正衔接到服务器上?可以通过查看服务器的日记,找出与运路程序时间呼应的Connect和Quit事件:
? ? 这条消息表示根本没有成立衔接.不幸的是,客户机程序1没有奉告我们呈现的这些后果.实际上它不能.它不能实现任何错误查抄,所以它乃至不知道自己发生了什么事.无论若何,当然不一定必须查看日记来探求能否能衔接到服务器!让我们立即改正它.在MySQL 客户机库中返回值的例程基本上以下列两种方法之一表示成功或失利:
? ? ■ 成功时,值的指针函数返回一个非NULL 指针,失利时返回N U L L(在这里NULL 的意思是"C NULL 指针",而不是"MySQL NULL 列值").迄今为止,我们利用的客户机库的例程mysql_init() 和mysql_real_connect() 都用返回衔接处理程序的指针来表示成功, NULL 表示失利.
? ? ■ 整型数值的函数普通成功返回0,失利返回非0.不要测试特定的非0值,如- 1.因为当失利时,并不保证客户机库函数返回任何特定的值.有时,您大概会看到像以下的较旧的错误地测试返回值的代码:
? ? 这个测试大概工作,也大概不工作.MySQL API 不将任何非0错误的返回指定为特定的值,而只判断它(明显地)能否为0.这个测试应当写成下面两段之一:
? ? 或以下所示:
? ? 这两个测试是等价的.假如考核MySQL 的源代码,则可以发现,它基本上用第一种情势测试,因为这编写起来更简短.
? ? 不是每个API 调用都返回值.我们利用的另一个客户机例程mysql_close() 就不返回值(它若何失利?失利了又若何?无论若何,都要举行衔接).
? ? 当客户机库调用失利,并且需求有关失利的具体信息时, API 中的两个调用都是有效的.mysql_error() 返回包含错误信息的字符串,而mysql_errno() 返回数值代码.应当在错误呈现今后立即调用它们,因为假如公布另一个返回状况的API 调用,则从mysql_error() 或mysql_errno() 获得的任何错误信息都将来自于背面的调用.
? ? 普通来说,程序的用户查看错误字符串比查看错误代码更有启迪.假如只报告二者中的一个,则倡议报告字符串.出于全面考虑,本章的这个样例报告两个值.考虑前述的谈论,我们将编写第二个客户机程序,即客户机程序2.它近似于客户机程序
? ? 1,但是适本地增添了错误查抄代码.源文件client2.c 以下所示:
? ? 这个错误查抄的逻辑是,假如失利,则mysql_init() 和mysql_real_connect() 都返回NULL.请注意,固然这个程序查抄mysql_init() 返回的值,但是,假如它失利,却不调用错误报告函数.这是因为当mysql_init() 失利时,不能假定衔接处理程序包含任何有意义的信息.
? ? 相反,假如mysql_real_connect() 失利了,则衔接处理程序并不反映有效的衔接,但是的确包含传送给错误报告函数的错误信息(不要将该处理程序传送给任何其他的客户机例程!因为它们普通假定是一个有效衔接,所以您的程序大概崩溃).编译和衔接客户机程序2,然后试着运行它:
? ?% client2
? ? 假如客户机程序2没有别输出,则衔接成功.另一方面,大概会以下所示:
? ? 这个输出表示没有成立衔接,并阐明为什么.大概,它还表示我们的第一个程序,即客户机程序1,没有成功地衔接到服务器(毕竟客户机程序1利用一样的衔接参数)!而在当时我们不知道,因为客户机程序1没有错误查抄.而客户机程序2做查抄,所以当出问题时,它可以奉告我们.这就是应当始终测试API 函数返回值的缘由.
? ? MySQL 邮件清单问题常常是与错误查抄有关的.典型的问题是"当发送这个查询时,为什么我的程序崩溃了?"或"我的程序怎么没有返回任何东西?"在很多情形下,在查询公布从前,有疑问的程序不查抄在公布该查询前能否成功地成立了衔接,大概不查抄在试着检
索后果前确保服务器成功履行该查询.不要假定每个客户机库都调用成功.
? ? 本章下面的例子完成错误查抄,并且也应当这样.看起来它仿佛有更多的工作,但是从长远地运行来看,它的工作实际上是少的,因为您化费了更少的时间来捕捉扑朔迷离的问题.在第7章"Perl DBI API"和第8章"PHP API"中,也利用这种查抄错误的办法.
? ? 目前,当运行客户机2的程序时,假定看到回绝拜候( Access denied)的消息.若何改正这个问题呢?一种大概是将主机名称、用户名称和口令的#define 行更改成答应拜候服务器的值.这是有好处的,在这个意义上,至少应当能做一个衔接.但是,这些值是程序中的固定编码.所以笔者倡议不要用这种办法,分外是对口令值.当将自己的程序编译为二进制格局时,您大概认为口令躲藏起来了,但是,假若有人在程序上运行strings,则它根本躲藏不住(更不用阐明读取拜候源文件的人根本不用做一点工作,便可以获得口令).
? ? 在"客户机程序4—运行时获得衔接参数"一节中我们将处理拜候的问题.首先,笔者
想阐明编写衔接代码的一些其他办法.
以上是“MySQL数据库技术(31)[MySQL防范]”的内容,如果你对以上该文章内容感兴趣,你可以看看七道奇为您推荐以下文章:
本文地址: | 与您的QQ/BBS好友分享! |