工作中遇到的令人头疼的bug

2018-06-18 02:32:02来源:未知 阅读 ()

新老客户大回馈,云服务器低至5折

 工作中我们会遇到形形色色的bug,但是很多bug都可以调试很明显的看出来,这种bug解决起来我们不会那么头疼但是有些却让人头疼而捉急,特别是本地运行一切正常,上传服务器就会出现bug。现在我总结几个我工作遇到的问题以及解决办法

1:有一次我为别的部门写一个服务接口,本地运行一切正常,但是到服务器就是报一个异常。

解决过程1:在本地先发布然后配置IIS,一切正常。然后把生成的bin文件替换服务器上的bin文件,依然异常

解决过程2:然后在代码中加入日志,但是日志竟然什么都没有。真实见鬼,最后没办法找人商量还是没发现。

最终解决方案:把代码全部考到服务器然后进行调试最后发现内存不足。当然这种情况很少见的,如果出现确实很难找,有的时候在服务器放套代码我觉得还是有必要的。

2:一次我要往数据库添加一条数据,首先判断数据库是否存在然后添加数据,但是发现总是报已存在数据,我从数据库查询确实没有这条数据,我就纳闷怎么了,出鬼了吗,然后我又换种方法去看是否存在,但是查询还是存在,觉得很诡异

最终解决方案:原来我数据库连接错了,因为我们项目中连了很多库,里面很多服务,导致配置文件中还有两个连接库没改过来。所以在工作中如果发现数据库查询和代码中查询不一致的时候第一个要想到是否库连接不对

3:一次我发现我服务器上两个地方调用同样的方法但是返回结果不一样。用vs调试也没发现什么异常(其中一个是提供给别的部门调用的数据)

最终解决方案:最后发现提供给别人调用的接口配置文件中服务地址和自己项目配置文件不同。在工作中如果发现调用同一个方法返回结果不同,查询一下这两个地方调用服务是否一样。

4:一次我们调用一个服务,此服务专门解析打开一篇pdf文献的。但是刚刚10分钟之前还能打开的文献突然全部不能打开,正赶上项目要上线,部门一半以上的人都在解决这个问题,因为这个服务还需要调用别的好几个服务,然后一个个排除,最后都排除不是那几个服务出错,一群人整整找了5个小时都没解决。

最后解决方案:第二天我们老大偶然的发现这个服务队少了一个我们的地址一般都是<http://192.168.000.000/index.aspx/>红色是我们缺少了,真实令人吐血。所以工作中如果发现调用的服务前几分钟还可以打开,然后就打不开了,一定仔细对比两个服务

5:这是我们部门遇到一个非常难得bug整个部门一起找问题凌晨2点才发现错误。同样我们部署一个项目在服务器上,但是服务器打开就是白页面,我们打开的日志里跟踪发现说我们传输的uid为空,抛出异常,但是这个uid根本就不可能为空,因为链接传输的就有。大家查询服务,查询是否配置出问题了。

最后解决方案:由于权限不足,当去读cookie的时候没有权限导致读取的数值为空抛出异常。所以工作中一定要考虑服务器上的权限上问题,必须给予超级管理员权限,否则出现了问题及其难找,还有当我们注册组件的时候记得要用超级管理员身份,否则有时候就是注册不成功。

6:在工作我们大多都是和别人合作一个项目,这个估计大家都不喜欢,因为如果一个人那里停滞了就会导致项目不前,我个人认为和别人合作的时候一定要静下心来,不要总是抱怨,不停的说又是你的错,如果遇到错误大家一起克服,一起商量然后自己也能学习很多东西。

7:正式项目中记得加入日志,否则出了错误很难找,有了日志就让我们找错误简单了很多。我个人觉得日志是蛮重要的。

 

 

标签:

版权申明:本站文章部分自网络,如有侵权,请联系:west999com@outlook.com
特别注意:本站所有转载文章言论不代表本站观点,本站所提供的摄影照片,插画,设计作品,如需使用,请与原作者联系,版权归原作者所有

上一篇:字符串 批量 替换 问题

下一篇:C#中命名空间别名的使用