Talk:Abort, Retry, Fail?

message: As someone who has seen A/R/F thrown out as the stereotypical example of confusing and/or stupid error messages, I find it puzzling that this cultural reality is not included in the article.  Yes, there are concrete meanings for each selection, but the computing community as a whole has long offered this dialogue as grist for justifiable ridicule. gloin (talk) 03:16, 24 October 2008 (UTC)
replies: text: I don't get this. I never found the message confusing. It just meant there was something wrong with what you were copying/running/ect. I found the error messages you get on the old macs and such where they have a bomb in message box and a hex number that relates to some sort of error code that it seemed only like three people in the world had the book that contained what that number meant in english. I mean in comparison the A/R/F message was great! No one likes an error message but as they go they don't get much better than this.--AresAndEnyo (talk) 01:33, 7 July 2009 (UTC)
replies: text:  This Artikle is a typical Example of a Windows-Troll complaining about Operationsystems he is inebt to use. There is nothing confusing about the Critical-Errorhandler (by the Way, this is the Interrupt 24h and you can simply intercept it inside a your Programm if you want to print something else - that should be written in the Artikle). Despite the Message beeing very intuitive in itself, DOS comes with a 800-Page Manual, that descripes every Aspect of the Operationsystem including this. The only Joke about the Handler is the Prank-Message Your Wife is Pregnant - (A)bort (I)gnore (F)ail but this is basically a joke about Pregnancy and less about DOS.  — Preceding unsigned comment added by 79.210.12.39 (talk) 21:40, 2 August 2013 (UTC)
replies: text: Replacing the handler *is* described in the article. And you should be well aware that Windows has long ago replaced this with the correct (and trivial to implement) behavior of returning "Fail" all the time, without prompting the user. If you think "Abort, Retry, Ignore" is so great, and also think Microsoft is so great, can you explain why they changed it? I'll tell you why: because even Microsoft realized they made a mistake, proving they are smarter than you in your insane belief that they are holy perfect.Spitzak (talk) 00:39, 3 August 2013 (UTC)
thread_title:  Example of bad user interface 

message: I would like to see the "popular culture references" section returned.  I think it is interesting to see how a relatively obscure operating system error message entered the wider culture and became a relatively well-known phrase.  It seems to me that wider use is what makes a simple DOS error message worthy of an encyclopedia article. —Preceding unsigned comment added by Seitz (talk • contribs) 
:I agree. The crossover into popular culture is definitely worthy of mention. I've restored the section, but it would be nice if it was expanded, or if more examples were added. Ae-a 13:22, 31 May 2006 (UTC)
thread_title:  Popular culture references 

message: I don't have an old computer handy to check for myself, but didn't the four-option version actually read, Abort, Retry, Fail, Ignore? I thought that "Ignore" came last when available. Can somebody verify this with old hardware? Matt Gies 01:17, 23 January 2007 (UTC)
replies: text: Well, 640k should be enough for everybody.  (Sorry, couldn't resist!)  --DachannienTalkContrib 18:33, 16 February 2007 (UTC)

text: The MS-DOS 3.20 manual specifies "Abort, Retry, Ignore?".  As far as I remember, it was "Abort, Retry, Ignore, Fail?" in later versions. -86.137.136.182 11:26, 9 September 2007 (UTC)
thread_title:  "Abort, Retry, Ignore, Fail?"? 

message: Yes this is serious.  The meanings of Abort Retry and Fail in this message were actually disntinct.  Abort would cause the program to return a TRUE value, fail would cause it to return a false value, and retry would simply retry the operation to see if something changed(like a disc being placed in a drive).  Again, I'm totally serious about this concern.  i kan reed 00:58, 14 March 2007 (UTC)
replies: text: You're joking, right? If there's a factual inaccuracy in the article then state your reason here and make the change. I see no POV issues at all --DrFod 15:42, 27 March 2007 (UTC)
replies: text: No, I'm sadly not joking.  And no, it's not regarding factual inaccuracy.  The tone of the article is actually somewhat hostile.  I know it's silly, but that doesn't mean it's not a concern. i kan reed 15:44, 27 March 2007 (UTC)

text: Hostile to the message itself.  It asserts bitterness in people without so much as a source on the subject. Now that you mention it, I'm worried I might have caught bureaucracy from too many unprotected AfD's... i kan reed 03:34, 30 March 2007 (UTC)
replies: text:  Well please change the article then so the NPOV tag can be removed. Gillyweed 11:17, 1 April 2007 (UTC)

text: I agree with 'Ikanreed' the article seems overly harsh on the error message design. See my message above under poor user interface or something.--AresAndEnyo (talk) 01:36, 7 July 2009 (UTC)
thread_title: NPOV

message: I just rewrote the bulk of this article.  The previous version did not cover the why-and-how behind this infamous message at all.  Also, the critical error handler could be invoked for write as well as read, and even for non-disk errors, although that was very rare.
I've tagged my own content as potential original research.  A lot of this I know from years of experience.  I have probably read about most of it at some time or another, but it's been a long time since DOS, so I can't cite specific sources, which we really should have.  Hence my tag.  If anyone can find sourcing, that would be fantastic.
Regards, —DragonHawk (talk|hist) 23:06, 29 July 2010 (UTC)
replies: text: I think there could be some more explanation of how bad this is. Blaming it on "primitive character oriented UI" is very misleading. The MSDOS behavior was wildly inconsistent: a missing file does not produce this popup, despite the fact that the user could "fix" it by changing the disk in the drive. It would have been trivial to have the functions fail in the same way that a missing file did by returning an error to the program. They did not do this because they wanted old CP/M software to work without changes and CP/M instead hung forever when the disk drive was open, they tried to "improve" this but were extremely paranoid about back-compatibility so they did not do the obvious thing of telling the program that the operation failed. It was fairly easy to replace the handler but in fact the design was very horrible, in that changing the handler to be "return an error from the system call" required unwinding the stack rather than any obvious return value.Spitzak (talk) 19:48, 16 August 2010 (UTC)
replies: text: That's even more original research than my existing commentary.  And decisions about backwards compatibility are always a compromise; if they did what you preferred they would break existing software.  Find a reliable source which agrees with your reasoning and I'll even write the article for you, but if we're going to get into "They should have done this", we really need sources.  —DragonHawk (talk|hist) 15:25, 17 August 2010 (UTC)

text: I am attempting some fixes that have no original research, except for my clear memory of having to do some nasty trick to make the interrupt act like "fail" and finding that in magazine articles indicating that it was by far the most common fix for this. I still do not like mentioning the CLI, as too many people seem to think that it would be "user friendly" if only the message was in a nice proportional font in a pop-up dialog box, when in fact that has NOTHING to do with how "user friendly" it is.Spitzak (talk) 20:34, 17 August 2010 (UTC)
thread_title:  Rewrite 

message: Okay, so, we have this:
: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.
I have some problems here:
# Relying on the default critical error handler, in and of itself, was not "broken".  Why write your own routine to prompt when the OS provides one already?  Programs were "broken" when they did not handle the "Failure" status properly, not because they didn't provide their own handler.
## In particular, the default critical error handler was used by DOS itself, in the various internal and external commands.  These programs weren't "broken" because of that; there was nothing to "fix".
## I'm not sure I buy that "Not handling 'Failure'" had anything to do with CP/M heritage; here in 2010, programmers aren't any better about not checking return status.
## You argue that telling the program the operation failed is the obvious thing.  I don't see that as obvious.  Why require every program to write their own routine to say "Hey, you forgot to close the disk drive"?
:::Programs typically responded to "file not found" by allowing the user to type a new file name. They would respond the same to this error, allowing the user time to close the drive door.Spitzak (talk) 21:21, 17 August 2010 (UTC)
replies: text: I think your description of why this is user-unfriendly is excellent.Spitzak (talk) 21:21, 17 August 2010 (UTC)
replies: text: Wrong. "File not found" is fixable by changing the disk to one that has the file on it!Spitzak (talk) 21:21, 17 August 2010 (UTC)
thread_title:  Changes 17 Aug circa 19:50 

message: Should there be a link to the "Abort, Retry, Ignore" parody of The Raven?
http://www.annoyances.org/exec/show/article09-122
It seems to be fairly well-known in hacker culture and conveys the despair of a user who can only really choose "Retry" in order to prevent work loss.
91.86.58.191 (talk) 21:06, 14 September 2010 (UTC)
thread_title:  Include link to famous "Abort, Retry, Ignore" parody of The Raven? 

message: Anyone want to add anything about the occasional practice of placing an object on the R key to provide a continual stream of retries? (Usually to overcome a poor-quality or dying floppy, where repeated retries may eventually produce a good-enough read.) -- SheeEttin (talk) 05:40, 4 March 2011 (UTC)
replies: text: Where's the reliable source?  Where's the notability?  Wikipedia is not an instruction manual i kan reed (talk) 17:44, 17 May 2011 (UTC)
thread_title:  Weighting down the R key 

message: I looked at prior versions of the article stating that Abort behaved like Retry on some systems, which is not necessarily true. However, both Abort and Retry did return to the same message "Not ready reading drive –". In these cases the Fail option would return to a prompt. There are newer versions in which both Abort and Fail would return to a prompt. mechamind90 20:00, 23 August 2011 (UTC)
replies: text: First any such info should not be under "user experience" but in the technical description above. Second, this needs a reference to be believable. I think you are confused by the ability of programs to trap the DOS exit and thus trap the "abort" so they really did not exit. Conversely I think you are confused by "Fail" because the program is free to decide what to do with the returned error, and one possibility is to exit. Thus "abort" might not exit, and "fail" certainly could exit. Behavior of the program is not part of the critical error handler, and to keep things simpler it is best to describe what it did and what it acted like the program would do with the results.Spitzak (talk) 22:59, 23 August 2011 (UTC)
thread_title:  Abort didn't always work that way. 

message: While the article makes a very good point of explaining why this error message (and the underlying error handling) might be considered a prime example of bad design, i think it neglects to mention what is probably a main reason for its discontinued use: The emergence of multi-tasking operating systems, where any of a number of applications and even more background processes could be the reason for the sudden appearance of such an error message; in fact, such confusing messages popped up on the screen fairly regularly on early multi-taskers from Microsoft, such as Windows 3.1 or even 95/98/Me, when forgotten or poorly-designed programs tried to access some drive in the background. The user was often left without a clue as to which program attempted the access and thus caused the popup. With such systems (which furthermore were more often left running unattended), it became increasingly clear that the only reasonable option was to return failure to programs making such access attempts.  — Preceding unsigned comment added by 79.168.82.183 (talk) 02:52, 5 December 2018 (UTC)
replies: text: If this analysis can be cited to a reliable source, it may be appropriate to include in the article.  — BillHPike (talk, contribs) 03:22, 5 December 2018 (UTC)
thread_title:  Neglected Reason For Demise Of Abort/Retry/Fail