Detecting disk errors
By Kent Reisdorph

If your application uses floppy disks, then you should be prepared to handle any potential disk errors. A disk error occurs when there’s no disk in a floppy drive, when a disk in the floppy drive isn’t formatted, when the disk is damaged, or for many other reasons. Handling disk errors gracefully makes your application more robust and saves your users from endless frustration.

In this article, we’ll explain how to handle disk errors in your application. We’ll also look at the SetErrorMode and GetLastError functions of the Windows API.

Why handle disk errors?
Windows handles critical errors at the operating-system level by default. If, for example, you try to write to a floppy disk and the diskette in the drive isn’t formatted, Windows displays a message box stating that a disk error has occurred. An example of this type of message box is shown in Figure A.

Figure A: An error message box for an unformatted disk (Windows NT 4).

While handling critical errors at the operating-system level is fine for many applications, some applications need better control of such errors. For example, if your application writes to diskette, you may want to suppress the normal Windows error message box in order to do some processing behind the scenes. Or maybe you just don’t like the message boxes that Windows provides and you want to replace them with your own message boxes. Whatever the reason, you occasionally need to take control of critical errors from Windows.

Two steps to success
Handling disk errors is a two-step process. First, we must inform Windows that we don’t want it to display critical error messages. We can accomplish this by calling the SetErrorMode function. Second, we must determine whether an error has occurred for any operations that could produce a diskette critical error. The GetLastError function provides an error code for the last system function called. We can use that error code to determine what went wrong. Let’s take a look at each of these steps in more detail.

Setting the error mode
As we indicated, Windows usually takes the responsibility for handling system errors. You can override that behavior by calling SetErrorMode with the appropriate flags for the types of errors you want to handle. In this case, the flag in which we’re interested is the SEM_FAILCRITICALERRORS flag. To tell Windows that you want to handle this type of error yourself, call SetErrorMode with the line:

SetErrorMode(SEM_FAILCRITICALERRORS);

After you’ve called this function, Windows will no longer handle critical errors.

That’s not the whole story, though. Make sure you save the old error mode and reset it when you’re finished with a particular operation. We’ve done so in this example:

int OldMode;

OldMode = SetErrorMode(SEM_FAILCRITICALERRORS);

// Do some things that might cause an error

// and then reset the error mode.

SetErrorMode(OldMode);

As you might have surmised, SetErrorMode returns the previous error mode setting, thus allowing you to save the current error mode so you can restore it after you’ve completed a particular operation. Reset the error mode as soon as you’ve finished your processing. If you fail to do so, then the user may not receive notification of certain errors that are out of your control as a programmer. In short, do the following:

• Set the error mode as desired.
• Do your thing.
• Set the error mode back to what it was before.

By following this guideline, your applications can have custom error handling—yet not interfere with normal Windows operations. By the way, you can catch other errors besides critical errors. See the SetErrorMode topic in the Win32 API help file for complete information.

Detecting errors
Once you’ve told Windows that you’ll be detecting critical errors, you must check with Windows to know when an error occurs. You use the GetLastError function to do this. Let’s say, for example, that you wanted to copy a file to a diskette in drive A. You might go about it with the following code:

OldMode = SetErrorMode(SEM_FAILCRITICALERRORS);

CopyFile("test.dat", "A:\\test.dat", false);

int error = GetLastError();

// code to handle error here

SetErrorMode(OldMode);

Since you could get any number of errors from this operation, you must be prepared to handle them all. For example, the CopyFile function in the previous example could result in any of the following errors:

And this is just a sampling. Other errors could also apply. (Note: For a complete list of error codes, check out WINERROR.H. This header file contains a complete list of Windows error codes and a brief description of each.)

You must take great care to handle any possible errors that might occur as the result of a file operation (or any other operation for that matter). You don’t need to handle each and every error specifically, but you must at least let the user know about errors that you aren’t handling. (See the sidebar "Getting Error Message Text" for a description of how to obtain the Windows error message text for errors that you don’t handle directly.)

You should also be aware of one other thing concerning GetLastError. Windows NT and Windows 95 don’t necessarily return the same error code for identical disk error conditions. For example, if you attempt to set the current directory to a floppy drive that contains an unformatted disk under Windows NT, GetLastError will report an error code of ERROR_UNRECOGNIZED_MEDIA. On the other hand, under Windows 95 GetLastError might report ERROR_GEN_FAILURE or ERROR_INVALID_DRIVE for the same operation. Be sure to test your applications thoroughly under both operating systems so that you know your code will work on either platform.

Conclusion
Listings A and B contain a program that illustrates using SetErrorMode and GetLastError to detect disk errors and acting accordingly. As an added bonus, the program uses the FormatMessage function to display any errors not handled by the program. The program checks whether the diskette in drive A is good. If not, it reports an error. If you subscribe to C++Builder Developer's Journal, you can also get the code for this example from our Web site at www.zdjournals.com/cpb; click on the Source Code hyperlink and look for the file 98JUN.ZIP.

Custom error handling is vital in certain types of applications and a nice feature in others. Although you might not need SetErrorMode often, when you do, you should at least know how it works.