一次Debug的经历(Django开发)

现象:
view执行到render_to_response时就卡住,使页面无法显示。

解决过程:
由于可以确认没有改过这部分代码,所以怀疑是浏览器或是系统的问题,所以做了如下尝试:

  •     换个浏览器(无效);
  •     重启MySQL(无效);
  •     重启系统(无效)。


到此时就有点怕这个Bug了,明明没有改过代码,怎么就会突然问题呢?怀疑可能自己改了代码忘了,或是由于其它人更改代码引起的。
尝试使用另一个版本库中的代码(前一次更新用的代码,可以确认能够使用),所出现的现象相同。这下就没头绪了,于是把问题抛给了张顾问。
他给出的解决思路是:

  • template tags 里有死循环
  • 如果render_to_response里不传递数据呢?只render模板看看
  • 看一下settings里的模板是不是绝对路径?
  • 去掉模板的extends先


可以确认template tags里是没有死循环的,所以试了第二点,发现只render模板是可以的。
此时,可以确认是数据问题,而且对这个问题的解决也有了思路,即:一点点往模板时传数据,如果出现相同现象就表明是刚才传入的数据有问题。
终于发现的出现问题的数据,于是尝试在PY解释器里执行相同的取数据的代码,没出现错误。再是注释掉使用此数据的模板代码,只传入数据,页面可以显示。
查看模板代码,发现除了直接取数据的代码外,还有执行数据对像的函数的代码。注释掉函数调用,页面可以显示。
终于可以找到出现问题的函数了,修正错误后,页面正常显示。而导致出错的数据是在增加其它功能的时候产生的。

经验:
在模板中调用Model的函数,函数如有死循环会导致页面无法加载且无出错信息。

教训:
一定要相信事出必有因,且在遇到看起来比较诡异的问题的时候不要乱,通过增加调试语句来获得更多的信息,一点点排除可能的原因就能够将问题解决。
虽然学过穆勒五法,知道如何归因,但思考问题时还是不能像哲学家那样有条理的一步步的找出Bug产生的原因。

原文地址:https://www.cnblogs.com/crafter/p/2262923.html