Abort, Retry, Fail?
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 was sometimes used as an example of poor usability design in computer user interfaces.
Background
The DOS family of operating systems (such as MS-DOS, PC DOS and DR-DOS) date back to early microcomputers, which were primitive by modern computing standards. A primary design consideration was that software written for CP/M be portable to DOS without changes. In most CP/M systems attempting to read a disk drive with the door open hung waiting for an input event until the disk drive door was closed, on some hardware it would hang until an actual physical disk was in the drive. Many users of CP/M were accustomed to this as a method of managing multiple disks, by opening the disk drive to stop reading until the correct disk could be inserted. Even the first IBM-PC had more advanced hardware such that the CPU could tell that the disk drive door was open, but returning an error would break software that assumed it could not open a file until the user had closed the drive door. Still it was desirable to improve the experience if possible.
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 whether it should wait for the user to load a disk, or abort the operation. The handling of different errors was somewhat illogical, for instance while no disk in the drive caused the error, the wrong disk in the drive caused an immediate return with an error, even though that was also fixable by the user.
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.[1] The default critical error handler was part of COMMAND.COM[1] and it printed the "Abort, Retry, ..." prompt and waited for user input. Internal DOS commands and most of the line-oriented external commands included with DOS take advantage of this and do not install their own handler.
A program can install its own critical error handler while running, and many of the more sophisticated programs,[1] in particular full screen programs, do so in order to avoid the messages disturbing the normal output of the program. Some software faked the missing "FAIL" response by jumping back to the calling program, skipping the return stack in DOS, a risky hack.
Starting with MS-DOS/PC DOS 3.3, the ability to return "FAIL" from the critical error handler was added, which removed the biggest problem with the prompt (which earlier was known as "Abort, Retry, Ignore?") in that there was now a useful value to return that did not crash the program or repeat the prompt. DOS 3.3 COMMAND.COM provides the startup option /F in order to force the default critical error handler to return "Fail" on errors. This option is intended for unattended use, for example in conjunction with BBS software, as network server, or in embedded systems. The option is also supported by COMMAND.COM of PTS-DOS 6.51 and S/DOS 1.0, as well as by DR-DOS 7.02 and higher. OpenDOS 7.01 COMMAND.COM provides a similar feature to not install a critical error handler when startup option /N is specified, a feature, which is still supported in newer versions. Starting with version 4.0 the alternative command line processors 4DOS and NDOS support option /F and the corresponding 4DOS.INI/NDOS.INI directive CritFail=Yes as well.
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.[2]
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.[2] 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 DOS 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.[2] "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) (older versions of DOS): Return success status to the calling program/routine, despite the failure of the operation.[2] 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 behavior.[2] "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.
- Fail (F) (DOS 3.3 and later): Return failure status to the calling program/routine.[2] "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.
User experience
These messages have become an example of frustrating and useless computer messages in popular culture. 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 1993, Neil Howe published 13th Gen: Abort, Retry, Ignore, Fail?, a sympathetic book about the culture of Generation X.[3]
In 1996, White Town released an EP entitled >Abort, Retry, Fail?_.[4]
PC Magazine has used the term as the title of its column highlighting humorous computer-related errors.[5]
In the game Sid Meier's Alpha Centauri, this term is used in the technology tree quotation for Nanomatter Editation: " 'Abort, Retry, Fail?' was the phrase some wormdog scrawled next to the door of the Edit Universe project room. And when the new dataspinners started working, fabricating their worlds on the huge organic comp systems, we'd remind them: if you see this message, always choose 'Retry.' "[6]
See also
References
- 1 2 3 Randy Hyde (29 Sep 1996). "19.1.3: Exception Handling in DOS: The Critical Error Handler". The Art of Assembly Language Programming.
- 1 2 3 4 5 6 "Action Taken on Abort, Retry, Ignore, Fail (67586)". Microsoft Knowledge Base. Microsoft. 2006-11-16. Retrieved 2009-04-18.
- ↑ Howe, Neil; Bill Strauss (1993). 13th Gen: Abort, Retry, Ignore, Fail? (1st ed.). New York: Vintage Books. ISBN 978-0679743651.
- ↑ "Abort, Retry, Fail?_ Your Woman". discogs. Retrieved 2008-04-18.
- ↑ Louderback, Jim (2006-05-03). "PC Magazine's Extreme Makeover". Retrieved 2008-07-27.
- ↑ http://www.gamefaqs.com/pc/198636-sid-meiers-alien-crossfire/faqs/53907
| ||||||||||||||||||||||||||