Abort, Retry, Fail?

This article is about an error message. For an EP of this title by White Town, see Abort, Retry, Fail? (EP).

MS-DOS prompts "Abort, Retry, Fail?" after being commanded to list a directory with no diskette in the drive.

In computing, Abort, Retry, Fail? is a computer error message in the DOS operating system which indicates a critical error and prompts the end-user for the course of action to follow. This and other similar error messages are given by the default critical error handler. The message is often used as a classic example of poor usability design in computer user interfaces.

Background

The DOS family of operating systems (such as MS-DOS and PC-DOS) date back to early microcomputers, which were primitive by modern computing standards. They were lacking in memory capabilities, so programs were often made as small as possible. DOS was limited to a text-only command-line interface for interaction with the human operator, which had similar limitations to those of modal dialog boxes in that the user had to answer each question in turn as it was asked by the computer.

In DOS, a critical error is one which might be fixable by operator intervention. The classic example is an attempt to read from the floppy drive without a diskette loaded. The computer has no way of determining if it should wait for the user to load a disk or abort the operation. It could have returned an error back to the program, similar to how it would act if the disk was in the drive but the file not found. However, most programs at this time simply exited and thus the user could not fix the problem and continue. DOS tried to make this possible without requiring the programs to be rewritten.

When DOS encounters a critical error, it generates software interrupt 24 (INT 24). The associated interrupt service routine (ISR) is called the critical error handler.

The COMMAND.COM shell provides a default critical error handler. The default handler is used by all internal commands, as well most external commands (utility programs included with DOS). Third-party programs could provide their own critical error handler, but many did not.

Default critical error handler

The default critical error handler is what generates the message. It would typically print a short (one line) description of the error code, followed by a prompt for user action. For example, if the user attempted the DIR command (display directory) with no disk loaded, the following might be displayed:

Not ready reading drive A
Abort, Retry, Fail?

The user was expected to press a single key to signal what they wanted DOS to do. The key to press corresponded to the first letter of each capitalized word in the prompt.

Responses

Depending on circumstances and DOS version, two or more of the following choices may have been offered:

• Abort (A): Terminate the operation/program and return to the system command prompt. In hindsight this was not a good idea as the program would not do any cleanup (such as completing writing of other files). "Abort" was necessary because early MSDOS did not implement "Fail". It may have remained necessary for poorly written software for which "Fail" would have caused a loop that would have repeatedly invoked the critical error handler with no other way to exit.

• Retry (R): DOS would attempt the operation again. "Retry" made sense if the user could rectify the problem. To continue the example above, if the user simply forgot to close the drive latch, they could close it, retry, and the system would continue where it left off.

• Ignore (I): Return success status to the calling program/routine, despite the failure of the operation. For instance, a disk read error could be ignored and DOS would return whatever data was in the read buffer, which might contain some of the correct data from the disk. Attempting to use results after an "Ignore" was an undefined behaviour. "Ignore" did not appear in cases where it was impossible for the data to be used; for instance, a missing disk could not be ignored because that would require DOS to construct and return some kind of file descriptor that worked in further "read" calls.

• Fail (F): Return failure status to the calling program/routine. "Fail" returned an error code to the program, similar to other errors such as file not found. The program could then gracefully recover from the problem. This option did not exist in MSDOS 2.0.

User experience

These messages have become the canonical example of frustrating and useless computer messages in popular culture^{[citation needed]}. The computer would not allow the user to proceed unless they picked one of the options, but to the novice user none of them produced a desirable result: "Retry" would just repeat the message, and (for most software) all the others would cause the program to exit and lose all work (for "Ignore" this was due to a crash). Thus one appeared to be faced with an endless repetition of the same message from "Retry", followed by lost work regardless of which second choice was made.

In popular culture

In 1996, White Town released an EP entitled >Abort, Retry, Fail?_.

PC Magazine has used the term as the title of its column highlighting humorous computer-related errors.

See also

• Bad command or file name
• Error message