我应该处理哪些错误？哪些是“致命的”？
某些 Windows 函数（例如 CreateFile）在调用 GetLastError 时可能会返回大量种错误代码，并且检查每个可能的错误代码是不切实际的-- 通常没有足够的文档，并且经常添加新的错误代码。
其中一些（例如访问冲突或无效参数）是由于程序员错误造成的，不应允许程序继续执行。然而，另一些则是由于其他因素造成的，例如错误的文件权限、共享违规、错误的文件名等，而开发人员几乎无法控制这些因素。
我想处理所有“非关键”错误（例如错误的文件名），同时允许“关键错误”（例如访问冲突）使我的程序崩溃。
理想情况下，我会说：
// ... an error occurred. Is it a programmer error?
if (IsErrorCritical(GetLastError()))
{
// Yes; raise an exception, crashing the program.
RaiseException(GetLastError(), 0, 0, NULL);
}
当我无法预测每个结果时，如何决定哪些错误代码可以安全地抑制（例如，在枚举磁盘上的文件时）？
Some Windows functions such as CreateFile could return a huge variety of error codes when GetLastError is called, and it's impractical to check for every possible error code -- there is often not enough documentation, and new error codes are added frequently.
Some of them (such as access violations or invalid parameters) are due to programmer error and should not allow continuation of program execution. However, others are due to other factors, such as bad file permissions, sharing violations, bad file names, etc., which the developer has little or no control over.
I would like to handle all "non-critical" errors (such as bad file names), while allowing "critical errors" (such as access violations) to crash my program.
Ideally, I would be saying:
// ... an error occurred. Is it a programmer error?
if (IsErrorCritical(GetLastError()))
{
// Yes; raise an exception, crashing the program.
RaiseException(GetLastError(), 0, 0, NULL);
}
How do I decide which error codes are safe to suppress (for example, when enumerating files on a disk), when I cannot possibly predict each and every outcome?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
“关键”取决于您对该文件执行的操作。
任何错误代码都可能是由于程序员错误或运行机器上的某些异常造成的；我认为这不是错误处理的重要区别。
对于您没有专门处理的错误（“未知”错误），只需假设文件未创建，然后处理这种情况。为什么它没有被创建并不重要，只要假设它没有被创建并考虑到这种情况即可。根据您的代码正在做什么以及您想在这种情况下投入多少精力，它可能是致命的，也可能不是致命的。
请注意，
GetLastError()不知道访问冲突，因此我不明白它与您的问题的相关性。"Critical" depends on what you're doing with the file.
Any error code could be because of either programmer error, or some exceptional thing on the running machine; I don't think that is an important distinction in error handling.
For the errors you don't handle specifically (the "unknown" ones), just assume the file was not created, and handle that case. It doesn't matter WHY it wasn't created, just assume it wasn't and account for that scenario. Depending on what your code is doing and how much effort you want to put into this scenario, it may be fatal or not.
Note that access violations are not something that
GetLastError()knows about, so I don't understand its relevance to your question.我认为这确实取决于具体情况，不可能一概而论，而是需要根据具体情况来决定。
我这么说的原因是，有时相同的错误代码出现在不同的上下文中，因此可以用来确定它是否重要的不是错误代码本身，而是上下文本身。
I think it really depends on the context, it is impossible to generally decide this instead it needs to be decided on a case by case basis.
The reason I say this is that sometimes the same error code comes in different contexts so its not the error code itself that can be used to determine if it is critical but the context itself.