servlet setattribute用法_servlet禁用session

大家好，又见面了，我是你们的朋友全栈君。如果您正在找激活码,请点击查看最新教程,关注关注公众号 “全栈程序员社区” 获取激活教程,可能之前旧版本教程已经失效.最新Idea2022.1教程亲测有效,一键激活。

Jetbrains全系列IDE稳定放心使用

这两天一直在做手机验证码的工作，ajax一下子就连通了，但是session存放发送给手机的随机验证码就无法读出来了（其实不是无法读出来,往下看），导致无法验证用户填写的手机验证码，于是我查了session的一些过期设置，还一度怀疑setMaxInteractiveInterval()的参数单位是不是毫秒。

弄了下个下午之后实在受不了，我一直往session是不是第二次请求action时就过期了的方向去思考，后来在别人的提醒下又研究了一下getSession（true）和getSession（false）的区别(默认缺省为true，表示试图获取存在的session，当session不存在时重新创建一个新的session返回，参数为false时则是尝试返回存在的session，当session实在不存在时返回null)。通过简单的if-else判断后发现上一次action操作session的确是仍然存活的，但程序就是在比较用户填写的验证码和session保存的系统发送的验证码时“卡了”，不往下执行了。
假设verify_code是1000，用户输入的inputCode也是1000

if(inputCode.equals(session.getAttribute("verify_code"))){
    System.out.println("1000==1000");
}
else{
    System.out.println("1000!=1000");
}

打印结果为1000!=1000，令人奔溃，跪了

尝试将对session.getAttribute(“verify_code”)的值进行强制转换，控制台没有任何打印输出，当然前台ajax也没有任何返回信息。

if(inputCode.equals((String)session.getAttribute("verify_code"))){
    System.out.println("1000==1000");
}
else{
    System.out.println("1000!=1000");
}

最后，实在受不了了，祭出大杀器，try-catch，加上后，才看到，不是程序“卡了”，原来是程序已经抛出异常了，类型转换异常，这时才想起，当初我往session存值的时候直接存的是生成四位int类型的数值，action用于接收用户填写的验证码当然是String类型，于是就出来了上面1000！=1000的结果。

所以，在存放已发送的验证码时在值后面加上“ +“””,问题就解决了。setAttribute()存的数据是什么类型，getAttribute()只能强制转换为什么类型。

最后总结一下，还是基础不扎实，还是要多做项目，多练手，写java代码时，要养成使用try-catch的习惯，遇到难题，就要用打印暴力调试，然后结合程序的逻辑进行思考。解决问题后，又是美好的一天。