|
精华帖 (0) :: 良好帖 (6) :: 新手帖 (13) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-08-25
最后修改：2010-08-25
抛出异常的爱 写道 pufan 写道 抛出异常的爱 写道 再次提示对于参数验证使用断言.
对于入力参数应该是全部被考虑到的 (录入错误也应该在逻辑之内, 属于鲁棒性编程方法) 如有不正确那需要防御编程方法 防御编程目的是找出代码出问题的点 而不是业务需要. 在jvm中还有关闭断言的方法. 正式环境下关闭断言. 开发测试下打开断言 PS:如果真的去面试楼上的众人全军覆没 太搞了你，对于3层架构的应用为啥要前后端双重验证清楚不，难道用户总那么规规矩矩吗。 假设一个验证是防止sql注入的，用断言做，正式环境一关闭，结果只能是杯具。 PS:如果真的去面试你肯定过不了 防止 SQL注入 --> 不是业务需要? 再八婆一下“业务需要” 没错，相对一般程序员来说，用户是你的客户，当用户提交一个表单，对表单的验证是业务需要。 对于类库编写者来说，一般程序员是你的客户，当程序员调用一个函数，对参数的验证在相对类库编写者来说一样是业务需要。 由此可见，没必要谈什么业务需要，忽略对调用方法的参数检查与忽略对用户表单验证的性质一样，都是不负责任不敬业的表现。 |
| 返回顶楼 | |
|
发表时间：2010-08-25
pufan 写道 抛出异常的爱 写道 再次提示对于参数验证使用断言.
对于入力参数应该是全部被考虑到的 (录入错误也应该在逻辑之内, 属于鲁棒性编程方法) 如有不正确那需要防御编程方法 防御编程目的是找出代码出问题的点 而不是业务需要. 在jvm中还有关闭断言的方法. 正式环境下关闭断言. 开发测试下打开断言 PS:如果真的去面试楼上的众人全军覆没 太搞了你，对于3层架构的应用为啥要前后端双重验证清楚不，难道用户总那么规规矩矩吗。 假设一个验证是防止sql注入的，用断言做，正式环境一关闭，结果只能是杯具。 PS:如果真的去面试你肯定过不了 防止SQL注入，我还是第一次听说用异常，还有用断言的，还有更加奇怪的是，Production环境居然开断言，debug你们开不开？ 有没有经验一下子就看出来了，别装了。 |
| 返回顶楼 | |
|
发表时间：2010-08-25
pufan 写道 抛出异常的爱 写道 pufan 写道 抛出异常的爱 写道 再次提示对于参数验证使用断言.
对于入力参数应该是全部被考虑到的 (录入错误也应该在逻辑之内, 属于鲁棒性编程方法) 如有不正确那需要防御编程方法 防御编程目的是找出代码出问题的点 而不是业务需要. 在jvm中还有关闭断言的方法. 正式环境下关闭断言. 开发测试下打开断言 PS:如果真的去面试楼上的众人全军覆没 太搞了你，对于3层架构的应用为啥要前后端双重验证清楚不，难道用户总那么规规矩矩吗。 假设一个验证是防止sql注入的，用断言做，正式环境一关闭，结果只能是杯具。 PS:如果真的去面试你肯定过不了 防止 SQL注入 --> 不是业务需要? 再八婆一下“业务需要” 没错，相对一般程序员来说，用户是你的客户，当用户提交一个表单，对表单的验证是业务需要。 对于类库编写者来说，一般程序员是你的客户，当程序员调用一个函数，对参数的验证在相对类库编写者来说一样是业务需要。 由此可见，没必要谈什么业务需要，忽略对调用方法的参数检查与忽略对用户表单验证的性质一样，都是不负责任不敬业的表现。 这不是在扯啊，抛哥说的JVM的方面，而代码逻辑中的验证是code上去的，不被JVM支配的。 还说一个开发流程咯，在发布到生产环境是要测试的，通过测试以后JVM assert可以去掉，代码逻辑验证肯定保留的。 |
| 返回顶楼 | |
|
发表时间：2010-08-25
楼上的fans一边去，知道讨论的什么吗，懒得理你。
|
| 返回顶楼 | |
|
发表时间：2010-08-25
pufan 写道 楼上的fans一边去，知道讨论的什么吗，懒得理你。
我不是他的fans,也不看他的星级，这基本的东西都不了解，建议少看点书，多思考一点。 |
| 返回顶楼 | |
|
发表时间：2010-08-25
pufan 写道 楼上的fans一边去，知道讨论的什么吗，懒得理你。
你先看说了什么再说话， mercyblitz 写道 showr 写道 一个方法的参数,C里面好像是一堆的if else判断参数是否合法,不合法就返回一个没有实际意义的值
但在java里面有异常机制,当参数不合法的时候,究竟是if else 一样判断后返回一个值 还是直接来个Exception ? 如果是 if else 的话,有什么好处 ? 如果是 exception 的话,又有什么好处 ? 或者是根据不同情况来定 ? 一次面试的题目,至今无解,求真相 if-else 方式的好处在于更贴近与逻辑思维，性能优于Exception。相对于Exception，其缺点是，不适合OOP，语义不明显，不易于错误错误跟踪或错误提示较少，并且类型比较单一（比如利用C语言的原生类型）或者难以统一（比如C语言结构和宏定义）。 exception方法的好处在于是业务逻辑和异常处理分离（代码相对清晰），try中处理业务，catch中处理异常情况。在API设计中，可以设计Exception Handler来处理异常，使得层次分明。同时，更好的OOP的封装和多态性。缺点在于性能相对差。 |
| 返回顶楼 | |
|
发表时间：2010-08-25
最后修改：2010-08-25
pufan 写道 抛出异常的爱 写道 pufan 写道 抛出异常的爱 写道 再次提示对于参数验证使用断言.
对于入力参数应该是全部被考虑到的 (录入错误也应该在逻辑之内, 属于鲁棒性编程方法) 如有不正确那需要防御编程方法 防御编程目的是找出代码出问题的点 而不是业务需要. 在jvm中还有关闭断言的方法. 正式环境下关闭断言. 开发测试下打开断言 PS:如果真的去面试楼上的众人全军覆没 太搞了你，对于3层架构的应用为啥要前后端双重验证清楚不，难道用户总那么规规矩矩吗。 假设一个验证是防止sql注入的，用断言做，正式环境一关闭，结果只能是杯具。 PS:如果真的去面试你肯定过不了 防止 SQL注入 --> 不是业务需要? 再八婆一下“业务需要” 没错，相对一般程序员来说，用户是你的客户，当用户提交一个表单，对表单的验证是业务需要。 对于类库编写者来说，一般程序员是你的客户，当程序员调用一个函数，对参数的验证在相对类库编写者来说一样是业务需要。 由此可见，没必要谈什么业务需要，忽略对调用方法的参数检查与忽略对用户表单验证的性质一样，都是不负责任不敬业的表现。 没写过类库. 不能体会这种 没有业务需要而需要验证状态 |
| 返回顶楼 | |
|
发表时间：2010-08-25
最后修改：2010-08-25
抛出异常的爱 写道 再次提示对于参数验证使用断言.
对于入力参数应该是全部被考虑到的 (录入错误也应该在逻辑之内, 属于鲁棒性编程方法) 如有不正确那需要防御编程方法 防御编程目的是找出代码出问题的点 而不是业务需要. 在jvm中还有关闭断言的方法. 正式环境下关闭断言. 开发测试下打开断言 能不能详细说说关于在参数验证中使用断言？一般我们只有在TestCase中段要测试的进行断言。而且如果你在开发测试中打开断言，那么正式环境中关闭断言。那是不是对系统会带来安全问题呢？ 我不是很明白LZ的想法。能否据个例子解释下呢？ 谢谢 |
| 返回顶楼 | |
|
发表时间：2010-08-25
jiangduxi 写道 抛出异常的爱 写道 再次提示对于参数验证使用断言.
对于入力参数应该是全部被考虑到的 (录入错误也应该在逻辑之内, 属于鲁棒性编程方法) 如有不正确那需要防御编程方法 防御编程目的是找出代码出问题的点 而不是业务需要. 在jvm中还有关闭断言的方法. 正式环境下关闭断言. 开发测试下打开断言 能不能详细说说关于在参数验证中使用断言？一般我们只有在TestCase中段要测试的进行断言。 http://lehsyh.iteye.com/blog/577499 引用 一、assert的开启和关闭
因为JVM默认是不启动assert的。因此，你可以使用标记 –enableassertions ( 缩写 -ea ) 来开启断言功能。同样，你也可以使用标记 –disableassertions ( 缩写 -da ) 来关闭断言功能。例： java - enableassertions AssertTest |
| 返回顶楼 | |
|
发表时间：2010-08-25
抛出异常的爱 写道 pufan 写道 抛出异常的爱 写道 pufan 写道 抛出异常的爱 写道 再次提示对于参数验证使用断言.
对于入力参数应该是全部被考虑到的 (录入错误也应该在逻辑之内, 属于鲁棒性编程方法) 如有不正确那需要防御编程方法 防御编程目的是找出代码出问题的点 而不是业务需要. 在jvm中还有关闭断言的方法. 正式环境下关闭断言. 开发测试下打开断言 PS:如果真的去面试楼上的众人全军覆没 太搞了你，对于3层架构的应用为啥要前后端双重验证清楚不，难道用户总那么规规矩矩吗。 假设一个验证是防止sql注入的，用断言做，正式环境一关闭，结果只能是杯具。 PS:如果真的去面试你肯定过不了 防止 SQL注入 --> 不是业务需要? 再八婆一下“业务需要” 没错，相对一般程序员来说，用户是你的客户，当用户提交一个表单，对表单的验证是业务需要。 对于类库编写者来说，一般程序员是你的客户，当程序员调用一个函数，对参数的验证在相对类库编写者来说一样是业务需要。 由此可见，没必要谈什么业务需要，忽略对调用方法的参数检查与忽略对用户表单验证的性质一样，都是不负责任不敬业的表现。 没写过类库. 不能体会这种 没有业务需要而需要验证状态 类库没写过，那真是在纸上谈兵。 |
| 返回顶楼 | |
