Abort, Retry, or Fail implies that there are three options which will lead to three different outcomes. My experiences lead me to believe that this is not the case. That all three options lead to the same outcome, which was usually to just repeat the Abort, Retry, or Fail message.

After studying Computer Science at Boston College and various theories and other such topics, I decided that what was really going on was that the programmers feared that the user would become aware very quickly that they had no control. Similar to a Choose Your Own Adventure book that only had one option at every "branch" in the story line, this would just not do. It would lead to a bunch of users who felt used.

As such, they created the Abort, Retry, or Fail message which implies the options and some choice which might lead to different outcomes.

Here is an explanation from a software perspective. The four options are actually Abort, Retry, Fail, Ignore? Depending on the version of DOS and the situation, not all options may appear.

This error is always produced during a call to the DOS API (generally via an INT 21h instruction). When some exception occurs, generally due to a hardware error, the user is queried as to the appropriate response. (This was considered a Good Idea back in the day.) In an arcane sense, the user is actually controlling the operation of the system call.

Abort will actually terminate the program in execution and return to the parent program, generally the DOS shell (COMMAND.COM).

Retry will cause the system function to be attempted again. If no error is encountered again, execution continues normally; otherwise the error message will recur.

Ignore immediately returns control to the calling procedure as if the system call had operated successfully, without error codes, even though the operation failed.

Fail also returns control to the calling procedure immediately, but returns the appropriate error code, usually in the AX register. This option is not available when there is no appropriate error code supported.

There is a reason that this error is so frustrating and the stereotypical behavior is to get it again and again regardless of the operation. This is because:

  • Retry will do no good if the nothing is done to rectify the source of the error. In some cases, such as a flaky disk sector, several attempts to read the data will eventually result in a success, and operation will continue. This is rare, in part because the disk is probed several times before the error is displayed anyway. On the other hand, if the error is a result of something simple like a missing disk, fixing the problem and choosing Retry will solve the problem.
  • The problem with Ignore and Fail is similar. Neither of these will result in successful performance of the operation, which is usually crucial to program execution. And as often as not, the program isn't checking error codes anyway, so Fail is no different from Ignore. Usually one operation producing Abort, Retry, Fail, Ignore is followed by another operation (like a successive disk I/O operation) that produces the same error. Even if it doesn't, behavior is usually undefined.
  • The only response that is somewhat reliable is Abort, which will often return the user to the DOS prompt, after quitting the program. Yet in the worst cases, even Abort fails because the command interpreter will be given control, and the first thing it tries to do is swap itself from disk back into resident memory. If this disk space is inaccessible, the error will recur yet again. This results in the user's perspective of an unending loop of error messages, halted only by shutting off the computer.

Log in or registerto write something here or to contact authors.