软件产品应如何处理访问冲突
我们有一个 C++ 语言的软件产品，由于编译器的记录问题会生成错误的代码（是的，我知道它本身很糟糕）。除其他错误外，此错误还会导致抛出访问冲突。
我们对此的反应是捕获错误并继续运行。
我的问题是，这是一种负责任的做法吗？当应用程序发生如此灾难性的失败时，是否有责任让其继续存在？警告用户然后死亡会更负责任吗？
编辑：
让异常不被处理的论点之一是访问冲突表明程序被阻止造成伤害，并且可能也没有造成任何伤害。我不确定我是否买那个。对此大家有什么看法吗？
We have a software product in c++, that due to documented problems with the compiler generates faulty code (Yes I know it is horrible in itself). This among other bugs causes Access Violations to be thrown.
Our response to that is to catch the error and continue running.
My question is, is this a responsible approach? Is it responsible to let an application live when it has failed so disasterously? Would it be more responsible to alert the user and die?
Edit:
One of the arguments of letting the exception unhandled is that Access Violation shows that the program was prevented from doing harm, and probably haven't done any either. I am not sure if I buy that. Are there any views on this?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
我同意 Ignacio 的观点：必须尽快修复该编译器，或者如果没有出现这样的修复，就跳槽。当然，这样做可能会遇到障碍，我猜您正在寻找实现该目标的短期解决方案。 :-)
如果错误代码问题不是非常狭窄局限于已知的、基本上无害的情况，那么我倾向于认为继续生产和运输带有错误代码的产品可能被认为是不负责任的，无论您如何处理违规行为。
如果这是一个非常有限受限的已知情况，那么您如何处理它取决于具体情况。你似乎知道问题出在哪里，所以你能够知道面对这个错误你是否还能继续下去。我倾向于报告并退出，但同样，这完全取决于实际的错误是什么。
I'm with Ignacio: It's imperative to get a fix for that compiler ASAP, or if such a fix is not forthcoming, to jump ship. Naturally there may be barriers to doing so, and I'm guessing you're looking for a short-term solution en route to achieving that goal. :-)
If the faulty code problem is not very narrowly constrained to a known, largely harmless situation, then I'd tend to think continuing to produce and ship the product with the faulty code could be considered irresponsible, regardless of how you handle the violation.
If it's a very narrowly constrained, known situation, how you handle it depends on the situation. You seem to know what the fault is, so you're in the position to know whether you can carry on in the face of that fault or not. I would tend to lean toward report and exit, but again, it totally depends on what the fault actually is.
实际上，这是不言而喻的，但是表现得好像程序做了一些它没有做的事情（当它应该在某个实际上是悬空指针的地方设置一些值时），或者没有做一些它不应该做的事情（当它随机化某个变量，不幸的是它成为悬空指针的目的地）。
损害最小化/缓解策略可能是对文件进行校验和（但不是以简单的方式；实际验证文件中未更改的数据是否未修改）并经常自动保存。
您认为客户意识到这个问题了吗？
Really it goes without saying, but it's irresponsible to act like the program did something it didn't (when it should have set some value somewhere which actually was a dangling pointer), or didn't do something it shouldn't have (when it randomizes some variable somewhere unfortunate enough to be the destination of a dangling pointer).
Damage minimization/mitigation strategies might be to checksum files (but not in a trivial way; actually verify that untouched data within the file is unmodified) and auto-save often.
Do you think the customer is aware of the problem?