2014 年 12 月 - 2 文章

jsp页面绝对路径的处理

  |   0 评论   |   0 浏览

file.jsp代码: <%@ page contentType="text/html; charset=utf-8" language="java" import="java.sql.,java.util.,java.io.*" errorPage=""%> <%@taglib prefix="s" uri="/struts-tags"%> <%@taglib prefix="c" uri="http://java.sun.com/jsp/jstl/core"%> <!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN" "http://www.w3.org/TR/html4/loose.dtd"> <html> <head> <% String path = request.getContextPath(); String basePath = request.getScheme() + "://" + request.getServ....

排除bug的一般性原则。为实践中所总结

  |   0 评论   |   0 浏览

版权声明:本文为博主原创文章,遵循CC 4.0 by-sa版权协议,转载请附上原文出处链接和本声明。 本文链接:https://blog.csdn.net/u012274449/article/details/41846921 进入项目中时,项目已经是后期了,需要开发的东西很少,反而是bug层出不穷。 所以很多时候都是在处理bug,以前自己开发的时候,出现bug,由于熟知业务逻辑,以及后台代码,所以想想就能大致确定出现问题的地点:是前台?是代码?还是数据库。 但是修改别人的bug,就不是这样了,这些bug神出鬼没,很难一眼看到问题所在。经常需要从前台一路跟踪参数直到数据库,才能找到出现问题的地方。 修改了一些之后,也有了一些想法。 总的来说,发现问题,确定问题要按照 从前到后,由表及里。 也就是先看看前台传递到后台的参数是否是正确的。是否有遗漏,是否有编码问题。 前台没问题,那么第二步, 查看输入数据库的参数,手动执行带参数的sql。 为什么不是接着解决业务逻辑问题,而是直接看输入到数据库的参数是否正确?因为业务逻辑通常很复杂,很难一眼看清全貌,就像改卷子,先看结果对不对,再看解题过程....