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

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.