Which errors should I handle? Which ones are "fatal"?

Question

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?

Answer 1

"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.

Answer 2

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.