|
精华帖 (0) :: 良好帖 (6) :: 新手帖 (13) :: 隐藏帖 (1)
|
|
|---|---|
| 作者 | 正文 |
|
发表时间：2010-08-25
pufan 写道 抛出异常的爱 写道 pufan 写道 抛出异常的爱 写道 pufan 写道 抛出异常的爱 写道 再次提示对于参数验证使用断言.
对于入力参数应该是全部被考虑到的 (录入错误也应该在逻辑之内, 属于鲁棒性编程方法) 如有不正确那需要防御编程方法 防御编程目的是找出代码出问题的点 而不是业务需要. 在jvm中还有关闭断言的方法. 正式环境下关闭断言. 开发测试下打开断言 PS:如果真的去面试楼上的众人全军覆没 太搞了你，对于3层架构的应用为啥要前后端双重验证清楚不，难道用户总那么规规矩矩吗。 假设一个验证是防止sql注入的，用断言做，正式环境一关闭，结果只能是杯具。 PS:如果真的去面试你肯定过不了 防止 SQL注入 --> 不是业务需要? 再八婆一下“业务需要” 没错，相对一般程序员来说，用户是你的客户，当用户提交一个表单，对表单的验证是业务需要。 对于类库编写者来说，一般程序员是你的客户，当程序员调用一个函数，对参数的验证在相对类库编写者来说一样是业务需要。 由此可见，没必要谈什么业务需要，忽略对调用方法的参数检查与忽略对用户表单验证的性质一样，都是不负责任不敬业的表现。 没写过类库. 不能体会这种 没有业务需要而需要验证状态 类库没写过，那真是在纸上谈兵。 对于这个题来说标准答案是断言..... 不是由于我常用断言.... 引用 3. 错误处理技术 这里主要讲述如何处理预期错误。 （1）终止程序运行 有些错误非常严重，如果出现，那么最好就的做法就是让程序终止并且让用户重启程序。例如，对于显示 X 光片的绘图程序，如果数据出错，那么就关闭程序，这个时候关闭程序要远远好于显示错误的数据。 （2）继续程序运行 有时候，错误出现了，但是没有必要去关闭程序，那么就有两种处理方案： a. 在例程中处理错误 例如让例程返回一个中立值，这是一种可行的方法，中立值在有些语言里面被描述为“类型的默认值”，例如整形的中立值为 0，指针的中立值为 NULL（或 null 等） b. 在例程外处理错误 返回一个错误码也是可行的，返回错误码意味着，错误将交由其他程序部分来处理，而不是本例程处理。 对于出现了错误，而没有终止程序的运行，这时候，你可以在日子文件中添加一个警告信息。 抉择：正确性和健壮性 有些程序要求非常高的正确性，而有些程序要求较高的健壮性，通常两者我们只能取其一。 （1）正确性意味着结果永远是正确的，如果出错，宁愿不给出结果也不要给定一个不准确的值。 （2）健壮性意味着通过一些措施，保证软件能够正常运行下去，即使有时候会有一些不准确的值出现。 4. 隔栏（barricades） 隔栏本身就是一组错误处理代码，对于内部类只需要使用断言而无需使用错误处理代码。当断言为假时，表明了问题出在了程序中而不是数据中，需要通过修改代码来消除问题。在此，请读者联系本文开始 --- “在非法输入（Invalid Inputs）中保护你的程序”这一部分进行思考。 |
| 返回顶楼 | |
|
发表时间：2010-08-25
最后修改：2010-08-25
抛出异常的爱 写道 pufan 写道 抛出异常的爱 写道 pufan 写道 抛出异常的爱 写道 pufan 写道 抛出异常的爱 写道 再次提示对于参数验证使用断言.
对于入力参数应该是全部被考虑到的 (录入错误也应该在逻辑之内, 属于鲁棒性编程方法) 如有不正确那需要防御编程方法 防御编程目的是找出代码出问题的点 而不是业务需要. 在jvm中还有关闭断言的方法. 正式环境下关闭断言. 开发测试下打开断言 PS:如果真的去面试楼上的众人全军覆没 太搞了你，对于3层架构的应用为啥要前后端双重验证清楚不，难道用户总那么规规矩矩吗。 假设一个验证是防止sql注入的，用断言做，正式环境一关闭，结果只能是杯具。 PS:如果真的去面试你肯定过不了 防止 SQL注入 --> 不是业务需要? 再八婆一下“业务需要” 没错，相对一般程序员来说，用户是你的客户，当用户提交一个表单，对表单的验证是业务需要。 对于类库编写者来说，一般程序员是你的客户，当程序员调用一个函数，对参数的验证在相对类库编写者来说一样是业务需要。 由此可见，没必要谈什么业务需要，忽略对调用方法的参数检查与忽略对用户表单验证的性质一样，都是不负责任不敬业的表现。 没写过类库. 不能体会这种 没有业务需要而需要验证状态 类库没写过，那真是在纸上谈兵。 对于这个题来说标准答案是断言..... 不是由于我常用断言.... 引用 3. 错误处理技术 这里主要讲述如何处理预期错误。 （1）终止程序运行 有些错误非常严重，如果出现，那么最好就的做法就是让程序终止并且让用户重启程序。例如，对于显示 X 光片的绘图程序，如果数据出错，那么就关闭程序，这个时候关闭程序要远远好于显示错误的数据。 （2）继续程序运行 有时候，错误出现了，但是没有必要去关闭程序，那么就有两种处理方案： a. 在例程中处理错误 例如让例程返回一个中立值，这是一种可行的方法，中立值在有些语言里面被描述为“类型的默认值”，例如整形的中立值为 0，指针的中立值为 NULL（或 null 等） b. 在例程外处理错误 返回一个错误码也是可行的，返回错误码意味着，错误将交由其他程序部分来处理，而不是本例程处理。 对于出现了错误，而没有终止程序的运行，这时候，你可以在日子文件中添加一个警告信息。 抉择：正确性和健壮性 有些程序要求非常高的正确性，而有些程序要求较高的健壮性，通常两者我们只能取其一。 （1）正确性意味着结果永远是正确的，如果出错，宁愿不给出结果也不要给定一个不准确的值。 （2）健壮性意味着通过一些措施，保证软件能够正常运行下去，即使有时候会有一些不准确的值出现。 4. 隔栏（barricades） 隔栏本身就是一组错误处理代码，对于内部类只需要使用断言而无需使用错误处理代码。当断言为假时，表明了问题出在了程序中而不是数据中，需要通过修改代码来消除问题。在此，请读者联系本文开始 --- “在非法输入（Invalid Inputs）中保护你的程序”这一部分进行思考。 刚说完你纸上谈兵，你又抄这么一大段给我。。。 讨论的是java问题，而你给的很可能是C的编程规范。。。 |
| 返回顶楼 | |
|
发表时间：2010-08-25
allskylove 写道 都扯淡啊！怎么扯到断言去了，断言是一种测试 ！预测，不是正常流啊， 还不值得讨论这么多！ 楼主问的的什么，不要托提了!是不是都想自己表现表现自己，真是无聊的人啊，水平这么菜还唧唧问问的。
是够无聊的，我准备撤了。 |
| 返回顶楼 | |
|
发表时间：2010-08-25
抛出异常的爱 写道 jiangduxi 写道 抛出异常的爱 写道 再次提示对于参数验证使用断言.
对于入力参数应该是全部被考虑到的 (录入错误也应该在逻辑之内, 属于鲁棒性编程方法) 如有不正确那需要防御编程方法 防御编程目的是找出代码出问题的点 而不是业务需要. 在jvm中还有关闭断言的方法. 正式环境下关闭断言. 开发测试下打开断言 能不能详细说说关于在参数验证中使用断言？一般我们只有在TestCase中段要测试的进行断言。 http://lehsyh.iteye.com/blog/577499 引用 一、assert的开启和关闭
因为JVM默认是不启动assert的。因此，你可以使用标记 –enableassertions ( 缩写 -ea ) 来开启断言功能。同样，你也可以使用标记 –disableassertions ( 缩写 -da ) 来关闭断言功能。例： java - enableassertions AssertTest 补充一点，
private static void a(String s ){
assert s == null : //逻辑判断
"MUST NOT null"; //错误信息提示
}
|
| 返回顶楼 | |
|
发表时间：2010-08-25
pufan 写道 allskylove 写道 都扯淡啊！怎么扯到断言去了，断言是一种测试 ！预测，不是正常流啊， 还不值得讨论这么多！ 楼主问的的什么，不要托提了!是不是都想自己表现表现自己，真是无聊的人啊，水平这么菜还唧唧问问的。
是够无聊的，我准备撤了。 稍安勿躁！哥们先试试这种思维或者方法，不要不去验证就下结论啊！ 有句话什么来着：莫把无知当博学吧！试试吧！也许是一种办法呢？ |
| 返回顶楼 | |
|
发表时间：2010-08-25
最后修改：2010-08-26
错误码是早期编程语言处理错误的一种常见手段。异常则是Java等语言开发出来的专门处理错误的机制。
在早期，编程语言本身是没有异常处理机制的。如果一个函数或者一个类要告诉它的调用者我出错了，只能采用这种返回一个专门标识的方法。比如返回0成功，1失败。这样处理带来的一个很大问题就是每个错误码都是由开发人员自己定的。A写的错误码可能在B那里就是正确码。没有一个统一标准。如果没有相关的足够的说明文档的话，没人知道返回的这个码是什么意思。 为此，很多新语言在设计的时候开发了异常机制来进行错误处理。将各种错误定义成种种异常对象。使得程序员可以获得更加丰富的错误信息并确保被处理掉。 开发中，如果语言提供了异常处理机制，那么进行出错处理的时候当然要使用异常机制。只有在语言不提供异常处理的情况下，才考虑错误码。 |
| 返回顶楼 | |
|
发表时间：2010-08-25
jiangduxi 写道 pufan 写道 allskylove 写道 都扯淡啊！怎么扯到断言去了，断言是一种测试 ！预测，不是正常流啊， 还不值得讨论这么多！ 楼主问的的什么，不要托提了!是不是都想自己表现表现自己，真是无聊的人啊，水平这么菜还唧唧问问的。
是够无聊的，我准备撤了。 稍安勿躁！哥们先试试这种思维或者方法，不要不去验证就下结论啊！ 有句话什么来着：莫把无知当博学吧！试试吧！也许是一种办法呢？ 还是你比较适合，你去验证吧，等待着你由无知变为博学的好消息。 |
| 返回顶楼 | |
|
发表时间：2010-08-25
我有点想不通，既然异常是非正常状态下抛出的，为什么上面有很多人那么在乎它 的性能呢？谁的API没事干收到正常请求抛个异常当返回？ 我还从来没听说过抛异常成为性能瓶颈的情况。
异常抛出清晰明了， 用API的人一眼就看明白会有什么事情发生，抛RUNTIME的更是不负责任的设计，接口名 + 参数列表 + 异常，一眼就看出这个API要干什么事情，可能发生什么样的失败需要调用者处理，光靠返回值判断调用结果的代码见过不少，只有一个感觉：设计的真烂，再看看调用API的代码，一大堆IF + 常量，有的干脆连常量也不定义，上来就是一堆IF或者switch，典型的c时代过来的人，处理返回值处理多了吧， 这样的代码实在是让人看不下去。 至于前面有朋友说异常有可能抛到用户界面的情况，那不是异常的问题，是代码设计不合理导致的。正常的系统应该严格禁止掉向用户界面输出堆栈这种事情。无论哪里抛出的，都不应该暴露堆栈。而且这并不是很难处理的事情。 |
| 返回顶楼 | |
|
发表时间：2010-08-25
没有明确的场合，还是得具体情况具体分析了。
用Exception还算灵活吧，并且可以自定义，然后可以控制事务 if和else的出现会加大程序的易读性，维护起来是不太理想的 各有优势和劣势，所以只能看情况而定了。 |
| 返回顶楼 | |
|
发表时间：2010-08-25
强烈反对使用断言！强烈支持用Exception，特别是NPE，IAE，IndexOutOfBoundsException之类或者自定义的RuntimeException
有疑问的，请参考String.substring |
| 返回顶楼 | |
