当前位置：首页 → 问答吧 → 调试日志流程,错误分析的客观分析.

调试日志流程,错误分析的客观分析.

时间：2010-07-23

来源：互联网

引于此文.
http://bbs.phpchina.com/thread-189613-1-1.html

大家都知道, php自有一成套错误debug获取流程, 中文称为异常捕获. 如下语句:

<?php
function fun(){
throw new Exception('aaaa');
}
try{
fun(1);
}
catch( Exception $e ){
echo 'Catch exception here<br />' ;
echo 'Message: ' . $e -> getMessage (). '<br />' ;
echo 'More text or functions here.' ;
}

复制代码

可以看看这一句: throw new Exception('aaaa'); 是否跟大家写的友善提示很像? 判断一下,然后提示用户一些信息. 显然, 这种模式, 我们轻而易举的就可以处理好, 初学者甚至用exit效果也比自带的异常捕获要更为方便及人性化. 也许正因为这个原因, 所以我们很少在国内开发者的代码中看到这样的异常捕获. 比较常见有此异常捕获的, 多数在一些框架, phpmyadmin,及wordpress上, 国外开发者玩异常捕获乐此不疲.

其实我更欣赏的是mysql的异常处理, 在出错时, mysql_error()函数就可以调试出错误信息, 这点对于开发者很是方便. 比如非持久连接在遇到6秒断连的情况下, 你会发现一串正确的sql,为什么没有被执行呢? 如果你会mysql的异常调试, 你就会发现, 其实mysql给出的错误提示是 :mysql server has gone away 连接被关闭,无连接. 在更多的db封装类中, 都有封装一个错误调试方法, 列举出sql语句, 流程时间, 错误代码, 基础判断等等.

其实流程中, 更多的不是错误, 而是我们不知道何时, 何段,何行产生了错误. 这就是为什么要做一套完全的调试日志的原因. 我们就依discuz的post发帖动作试着思考:

1: 用户输入信息
2: 提交开始, 这一步会判断一下user pwoer.
3: 插入文章表,
4: 处理附件表.
5: 同步图片至uchome空间及相册, 缩略图.
6: 积分加减处理.
7: 通知服务, 比如回复通知, 事件通知.
8: 相应统计更新, 版块主题数, 用户主题数, 今天主题数.
............................ 当然还有很多.

复制代码

完善的系统是不可能出现说, 插入文章表后, 其它地方没有处理成功, 那也就算发帖成功了. discuz在发帖这一步, 类似于银行流程(未完全) 当附件及同步服务无法完成时, 就会回滚前面的操作, 使本次操作完全作废,提示相应的信息给用户. 那我们怎么能够知道它在哪一步出错了呢? 为什么出错呢? 是数据交互失败, 还是编码, 目录权限, 或者网络问题? 每一次post都是一个进程, 开发者没有办法在中途截取调试, 那怎么办?

这些就是操作日志, 是整个系统通用的.

我们可以在每一个环节, 截取相应的信息, 来分析流程的正确性, 比如检查附件_FILES是否提交成功, 文件名是否正确, 目录权限,错误代码等等. 这样一来, 我们就可以轻松知道错误出现在哪, 为什么出现错误, 可能是变量名写错, 数据传递失败等等, 这些日志也有助于整个系统的跟踪与调试, 在你的系统上线半年后, 你就能够分析错误代码的总数, 正常访问的总数, 偏向时间及区域等等.

如何记录变化多端的用户操作及开发流程呢? 这儿,许多人会知道, GET POST 数量及内容是我们没办法控制的, 有时一个POST 上100MB, 如果记录为日志, 肯定会对系统压力造成影响. 但不记录也不行. 可以用截取或者丢弃. GET　POST是两个值得学习和数组, 正如discuz的新版本代码中, $_G $SCONFIG 数组等等一样, 让我们知道了, 合理利用数组, 关于利用数组, 是多么的重要. 如果有可能, 请让你的所有变量都放在所能够控制的数组中. 比如: