Set*_*man 36 exception-handling exception
我有一个最佳实践问题.我意识到这是主观的,但是如果这是一种常见的编程习惯,我想问一下比我聪明的人.
如果你有一种非常重要的方法,你不想干扰应用程序的重要功能,那么使用像这样的错误接收器是否常见？
Try
'do stuff. not important if it fails.
Catch ex as exception
'sink. do nothing.
End Try
如果您正在考虑雇用我,而您正在阅读我的一些代码并看到了这个......对吗？
赛斯
编辑 哇!谢谢你的回答.我认为共识是永远不应该做的,或者它应该是非常罕见的.
我想我会给你这个问题的背景.首先,我非常熟悉Karl Sequin文章,并且已经遵循了这种模式多年.
但是今天在我正在进行的项目中,我正在完成更改列表并面临添加一个简单的功能.(如果您想知道......它正在为富文本框添加上下文菜单支持.)
所附说明称,"如果需要的时间超过15分钟......就放弃它."
所以我面临着添加一个潜在有用的功能但是没有时间来测试它不会破坏工作功能.对于记录,我们的此系统的异常处理程序具有处理和下沉或记录这些错误的机制.但是如果我正在开发一个没有强大错误处理系统的系统呢？是否可以添加此功能,如果发生错误......什么都不会丢失.
这是我的想法.但我已经把你的信息铭记于心......基本上这是一个坏主意.
赛斯
Dan*_*llo 13
是的,这很常见,但总的来说不应该这样做.
OutOfMemoryException除非您抓住它们尝试优雅地终止您的应用程序,否则有一些例外情况最好不会被捕获.
在大多数情况下,吞咽System.Exception或System.SystemException将不可避免地隐藏进一步的运行时问题.
你永远不应该隐藏异常.无论如何我可能会雇用你,但是当你为我工作时你不会这样做:)
但是,严肃地说,在Java中(例如)异常用于您可能选择忽略的某些情况,例如FileNotFoundException(像您一样,使用注释).但是如果你曾经遇到过类型的异常 - 就像IOException- 你不能只是隐藏它.如果Exception对您没有任何意义,请将其包装在一个RuntimeException并将其抛给客户端.
在某个地方,Exception应该处理,但从不隐藏.
这很常见,但最好避免它.至少你应该在某处记录异常.
另外,避免使用流控制异常.应编写您的代码以处理所有可能的情况,而无需诉诸异常.除了性能提升之外,此方法还告诉您,当异常发生时,值得您关注.
你不应该在这里捕捉所有例外.在极少数情况下,可以忽略特定的预期异常.但是,捕获所有异常并吞下它们将意味着您尝试在一个OutOfMemoryException和其他不可恢复的异常之后继续
虽然这里的大多数人实际上是在谈论开发者,但我想指出另一个观点.
我承认:我已经吞下了异常,并且在每种情况下都是因为恕我直言,这个功能的设计者搞砸了.
"例外"表示"例外",而不是失败或错误.我的意思是:如果函数必须确认输入可能不正确,我希望该函数不使用异常.我的愤怒特别针对"ParseException".
如果您解析输入,您很可能会发现未知/损坏/不精确的输入.这是"正常的",不是例外.在这种情况下,如果函数的开发人员抛出ParseException,如果函数无法正确解析,我会觉得很烦人.
为什么？
如果你打电话的时候,你是堵塞你的日志文件为parseFunction数千或数百万(!)究竟什么.
相比之下,我的理想函数给出了一个具有状态代码和消息的类对象
StatCode stat = parseXYZ(Reader r);
然后可以测试.
if (stat.code != OK)
//whatever
如果以另一种方式遇到您无法预见的问题(文件未锁定,无意义论证,非法线程状态)异常非常好.
| 归档时间： |
|
| 查看次数： |
1521 次 |
| 最近记录： |