joe@gistdev.gist.com (Joe Brownlee) (02/08/90)
In article <2820@cunixc.cc.columbia.edu> cmm1@cunixa.cc.columbia.edu (Christopher M Mauritz) writes: >What does this mean? I keep getting System Error #03 and a crash [...] For a machine that is based on friendliness and ease of use, the the error handling capabilities of the Mac OS are dismal. How many messages do we see here asking for info on bomb IDs, file I/O errors, or Sad Mac codes? Doesn't that say something about this whole issue? Wouldn't this be something that could be improved relatively easily? Note that I am _not_ flaming the people who post these questions -- they shouldn't have to hunt all over for error code meanings. All I ask is for a simple text message that concisely explains the error. Granted, text takes space, be it on disk, in ROM, or in memory, but I experience enough crahses that I would at least like to see a message in the bomb box. And file I/O errors like "Error #-39" should not make me reach for Inside Mac (which at least _I_ own; many users do not, nor should they have to). The Mac interface has many features which make it superior to others, but when it comes to its error handling, I just don't think ID=03 is acceptable. -- . _ Joe Brownlee, Analysts International Corp. @ AT&T Network Systems /_\ @ / ` 471 E. Broad Street, Columbus, Ohio 43215 (614) 224-6790 / \ | \_, joe@gistdev.gist.com Who pays attention to what _I_ say? "Scotty, we need warp drive in 3 minutes or we're all dead!" - Kirk
chuq@Apple.COM (Chuq Von Rospach) (02/08/90)
joe@gistdev.gist.com (Joe Brownlee) writes: >>What does this mean? I keep getting System Error #03 and a crash [...] >For a machine that is based on friendliness and ease of use, the the error >handling capabilities of the Mac OS are dismal. How many messages do we see >here asking for info on bomb IDs, file I/O errors, or Sad Mac codes? Doesn't >that say something about this whole issue? Wouldn't this be something that >could be improved relatively easily? Well, it could be improved (probably should be). Easily? That's another matter. One major reason the error handling is the way it is is because when you call the error manager the system is in a corrupted state (by definition). It can't assume that the OS is working properly, that quickdraw is working properly -- that ANY of the toolbox, or for that matter, the hardware, works. This is especially true of the sad mac codes, where there's been a catastrophic error that's bad enough the system can't boot. The error manager basically has to do everything itself. The question is, what level of tradeoff is acceptable between ROM size, memory usage (since the error manager has to be resident in memory: remember, when it's called, you can't trust loading stuff off disk into memory) and effusiveness. When it was first written, the ROM was tight on space and system memory had to be limited (there was only 128K, remember). Easily? There are a lot of complications to 'fixing' the error manager. >Note that I am _not_ flaming the people who post these questions -- they >shouldn't have to hunt all over for error code meanings. Agreed. One option is the System Error DA, which I find immensely useful. It's about 30K. What I question is whether it's worth putting that 30K into your system heap permanently just in case you get a system error. Isn't it better to have it there when you want to look at it but not having it take up your RAM? (30K is the size of the suitcase, which I'm using as a broad round number). Maybe a better option would be to bundle it (or a similar DA) with the systems and not take up system space or (worse) ROMs that would be out of date with every release of software. -- Chuq Von Rospach <+> chuq@apple.com <+> [This is myself speaking] Rumour has it that Larry Wall, author of RN, is a finalist in the race for the Nobel Peace Prize for his invention of the kill file.
wwtaroli@rodan.acs.syr.edu (Bill Taroli) (02/08/90)
In article <886@gistdev.gist.com> joe@gistdev.gist.com (Joe Brownlee) writes: >In article <2820@cunixc.cc.columbia.edu> cmm1@cunixa.cc.columbia.edu >(Christopher M Mauritz) writes: >>What does this mean? I keep getting System Error #03 and a crash [...] > >For a machine that is based on friendliness and ease of use, the the error >handling capabilities of the Mac OS are dismal. How many messages do we see >here asking for info on bomb IDs, file I/O errors, or Sad Mac codes? Doesn't >that say something about this whole issue? Wouldn't this be something that >could be improved relatively easily? Well, in defense of the Mac OS I would like to mention that I agree that the issue of using space in the ROMs for static text simply for error messages is important. Yes, it would be nice to have a cute little message telling you that the program you were just using ran out of memory (which would be cryptic in itself since it doesn't tell you WHY, and shouldn't be expected to in my opinion) but the cost/benefit ratio probably would suggest that it not be done. That is, would you like Apple to wire in another ROM or two to add these messages (thereby increasing the price, and with Apple's history this increase would probably be substantial) and really not know much more than you did with the numbers. True, the textual message can be more revealing but only to a certain extent. Those people interested in knowing why the crash occured will more than likely have the technical knowledge (and documentation) to figure the error number out. For those that don't, it probably doesn't matter... and it shouldn't have to (which is the whole strategy behind the Mac). Of course, this could lead to the question "If a non-technical user doesn't need to know why a crash occured then why have any message appear at all? Why not just have the system restart?". To this I would reply that it would likely not do too much for the reliabilty rating of the Mac... would you like your system to simply restart on its own after a crash without at least giving some indication that a problem occured? I know I wouldn't. Of course, if more people spent more time learning about program proving and metrics (and followed Apple's recommendations more closely) then occurences such as these would be less likely to occur. Oh well, that's my two bytes. Bill Taroli WWTAROLI@RODAN.acs.syr.edu -- ******************************************************************************* * Bill Taroli (WWTAROLI@RODAN.acs.syr.edu) | "You can and must understand * * Syracuse University, Syracuse NY | computers NOW!" -- Ted Nelson * *******************************************************************************
barmar@think.com (Barry Margolin) (02/08/90)
In article <886@gistdev.gist.com> joe@gistdev.gist.com (Joe Brownlee) writes: >The Mac interface has many features which make it superior to others, but >when it comes to its error handling, I just don't think ID=03 is acceptable. Chuq answered from the technical perspective. I think it could also be argued that this is reasonable human interface. Most situations that result in bombs or sad macs involve aspects of the system that are above the head of most computer users. They have to do with executing invalid opcodes, corruption of the heap, miscalling system routines, etc. The translations of these bomb id's are things like "Segment Loader Error". In general, the textual translation would be no more meaningful to the user than the numeric one. And so what if the user knows what the error is? There's still nothing he or she can do about it; it's a bug in the program or OS. What's worse, the user might think they understand the error if it were in English. However, this could be based on misinterpreting the technical terms that would necessarily be included (unless you can think of non-jargony ways to report the kinds of errors that result in bombs). -- Barry Margolin, Thinking Machines Corp. barmar@think.com {uunet,harvard}!think!barmar
levin@bbn.com (Joel B Levin) (02/08/90)
In article <33777@news.Think.COM> barmar@think.com (Barry Margolin) writes: |In article <886@gistdev.gist.com> joe@gistdev.gist.com (Joe Brownlee) writes: |>The Mac interface has many features which make it superior to others, but |>when it comes to its error handling, I just don't think ID=03 is acceptable. | |Chuq answered from the technical perspective. I think it could also be |argued that this is reasonable human interface. | |Most situations that result in bombs or sad macs involve aspects of the |system that are above the head of most computer users. . . . | The translations of these bomb id's are things like |"Segment Loader Error". In general, the textual translation would be no |more meaningful to the user than the numeric one. . . | |What's worse, the user might think they understand the error if it were in |English. . . This is all true, and I agree with it, but I think there is a perception that the user would be happier with a message like "Bus error" or "Segment not found" than with "System error 01". It is indeed not more useful to the user to see such a message, but it is easier for the user to remember when getting help for the problem, and I suspect it is psychologically more satisfying. More documentation for the necessarily arcane things like sadMacs should be in the back of the Macintosh user manual, however. If you are in a position to provide more useful information and help (Larry's description of the MacApp error handling capability is an excellent example) there is no excuse for not doing so, on the other hand. In a SysErr, this is generally not possible. (And a well written program reduces the odds of getting that far consdierably.) /JBL = Nets: levin@bbn.com | "There were sweetheart roses on Yancey Wilmerding's or {...}!bbn!levin | bureau that morning. Wide-eyed and distraught, she POTS: (617)873-3463 | stood with all her faculties rooted to the floor."
johnt@seila.UUCP (john grant) (02/09/90)
Granted it would be nice if the screen message was a little more lucid, but failing this and in the meantime, why not just enclose a printed copy with the machine. I know that this "reach for the bookshelf" solution is at best suboptimal, but then just bickering about this (for how many years now?) doesn't get us very far either. For cheapness, how about a Teachtext document that comes with the system update disks, then we could print our own ? John
freek@fwi.uva.nl (Freek Wiedijk) (02/09/90)
In article <51903@bbn.COM> levin@BBN.COM (Joel B Levin) writes: >This is all true, and I agree with it, but I think there is a >perception that the user would be happier with a message like "Bus >error" or "Segment not found" than with "System error 01". If your really think so: here is an INIT named Miner that replaces the *very* obscure text "Sorry, a system error has occurred" by a *much more* understandable explanation like "Bus error." :-) Enclosed is a little application named Bomber that can be used to generate an arbitrary bomb. It will show how Miner affects the messages in the bomb box. Hope this helps, Freek "the Pistol Major" Wiedijk Path: uunet!fwi.uva.nl!freek #P:+/ = #+/P?*+/ = i<<*+/P?*+/ = +/i<<**P?*+/ = +/(i<<*P?)*+/ = +/+/(i<<*P?)** -------------------------------- cut here -------------------------------- (This file must be converted with BinHex 4.0) :#8eTEQ9b,R0TG!"6593K8dP8)3#3""!!N!9H'e0*9#%!!J!!%!"b6'&e!3#3"`) !"8eTEQ9bFQ4*EQPd!*!d58j*9%9bFMmK!+'FJ$ZKR)0f!!!*U!#3"JG9!*!%2D3 !N!MAX`!!"!J)!%'hJ!F1"P`'TibF0QRQc%RcaJf)&b##d+&6TJdF1L$S[!(aTU& &+8'D&'L5aSe$!3561%P#TBJF16p#"!3fN!!J!$MQI-UND41R6J!m#3lKil1T6`' K1!(Di63"+MCP!"#4NmD13a"bbTKa@-E0Q$)Jh04T)qBVQ6GPjVJj!E*0'$TMd)# SibB05$TKa'#p#+++Qm#$4B))`iE0Qc&hdEETq%C1(K"Q+S10@iF0b$&[(-ZKJMM VeUjI)Fm&'AB1R)TN3Skm`T8138j1V2c$Kq3F!!a#6Vh3!3$2$ai!!+8#KH),#!C Q%"`()#!9-M"-AM")*FN%Nq$$!9#CVTbjFqM5N9HrcN)lGa"63M!"3!$q#`6"Mk0 bid3A!"JJI!##Fi#!-!%8J,`!J(lmqHIG0aJ!i)3A6Y64M%a&5!(#KJ903B88)a3 &JJKI`2""+%DiJ)J6dC!!D1+!S"c")N(+1"93EJ(e"J``)Z!JJ#XJZ%!I+&A)!NJ E"JL"K`,`J!%$$$J`b3!3!V9K!JKkr%-0#&$!!S8E()5"K4)3R'%"$$bJ)JL+3qJ $!")L))+QQN'i#8'-6(`c`!!6$[F2+4ALq1Bj`!!bTb"e!L"%M&Mq!`NS+B3"R"X !80!"&J"8d!)5!%#3!'F!I&+B$`)%03S(Pd'J3af86%i"""J'b!'!""K%%d`8b1a @B@q!&*LP%k#SF'LMcZ$j63!"J#&-3!-J!`!@#JK4aa`J1#4(C5ii%!3CC,4'VEA B8T!!4'0PR-%B##h03BFFGBa""d9ZZ-#!&Jk04%CADC!!8BB,%!b"4KPMV&%Y(QG p"+m,'e!K4aLR9N559h+BiGJG!aImEN8Z8!!&9hDNJG8CD(8FfPd(3k"`''G9A)E "'&I!4%YSa3#$c#%YI#UiFVMJ-X`Ja1"c$$8cA1e0f',!dKaR04D'5fp-Uc,,m@j J@"SHB6@C'ac&"PTBB$ApVNY#4T!!a!Y2J$"((ZTf025e19F`4EPAJq4B'2V+X6D f&4JappGRJ2"D5b$Kl!))3ba0&`KcamC'4(8Y(3E)GX1"mKU2leY"iDXKrJEGINp HHFmZR)$jiBQ$F1mF!VIN9aU-TD%(b3j,(R$P,S3`ZYbEakEZdQ5%)8GXCRL-PZb 8Jqa##lGVcVR%Qr2G`YpB,eBE'T1p1dERXaZr3[+PVlXddQATLr@jC[$P,VcB&lr [pSEMcMRJ$Kefm@&Xl2AZiZr'P6lYb,H[I'aLD)R[mY!#IBf"DZF#M4XJ0T(BHFj i$RK#(8$b"M1!B$*YU%`HA#!"lSA"I(S*(PCF-!%M#1q#3Y1AZUk9Kc+3!-%&$jJ #B!,f-)F`l`j#)XJ&R&!ZNRN&"&SBJaL-%*D3!$'Q$[ZbN4)$dJ($c-%K(6Y,DFc Q'*!!`1mQGIK)$TI)a5iqS!PPU31kU!@(1XJ"C#p-!IGbGm%`JN!-[M1G@&3h2lp GkbaN-11q5V"'cPe0M2S+APrU#)FlZP#2SHYME1l3NVG3,*!!G%4I)4pcb,#i!!@ +")%#ea8D13TbGE%cC"iY'C!!RY#(!!3K&A8J%"!JJ#!J%5!)+J(`!%"8S&0M!!3 !3-#"J,b5P5!J!#)#`!m%%)#B%"!%-4(bMq4mi"r!!)!($K"0(J`!(!$J`6b`b3G j`!-!IjM(0rm`$ML!maMQr--Md[Q*FAVLQcri"$CrX!pXIZ!6dEaR0!r36)(``bF %Q'9"!L)!9J,!PE#8T8pZb88)$-!I`RbS-4qD6(i'j*Q&qX%rjVP4F2jMR"m&`$p f)e+5MK3I*8AT592+dMq%e+A`l+K'l3P0!&K8L3FB#K@F`S'Lr)!J!8M#%*``JUB !`JK5+))4M&T+0Z6'(rUi$k4HF!%NZ1%IqV$U2rKK9DLQ!K8rF!&@Mc25rJ"!!6" 5`B3#CB@!['!"i1'"8)NDeV-Z*d"p!`%3)'8#*,`!!R9&J&NT!))P"1XqU4L&#Ei `)4GmSN*JX-G6@G'E(h$J"6K)!!'@i)kYKU!CQY8U2[E699DJiJe35J!,aJ%Y)%! J",$!3`*FF!B--!!A82JJ'a5!Kc-J)!Er4)"UB48$I#M!$kS0JM[m`3SBS!!!$#! !P9#!"##NPJ8Y!-)r6*!!hAqS`!#8!X%r@!$HAAVA"*453"KSF&dC#!N"DL#!$*! !J`*S"#%'`&!YDaAJfK$JGlDP488I3[!0cHB*"rbBd)#im!JR3#-*RF8!#KCK!%S 3""!jB!SU#5!%9J$!!#PJbLYIU3$Y&''jP&8$GC!!S!F!X%#V*TM1!)+$#RB3`-) "54!$N!#JBJ'`Z&-`RNi!D-b1#M9Pa+9-T8)53T!!C3#J!"R`3`%)3C!!AYVL`cS 9#!"d)#+#5-&$)#+)&qCDe)#S`DF%X305P8S333M"#85B6d!F!B"!"!3+5Y3P!ej TJ$Bm'31Q5-k(m3`!8"KeT&3+!+8+J!&M*'HN!5N!F4MYLi"!qX-qq,0r!((T*2e C&SrZT`'Dm'G9V!4QFMLe5q5!J#QJi3ehd#N#!!C#EfeLCA*N5@jTG!#30%&38%a #68*5)3#KQe0iSCYCm!!!#Bd!N!B(Y3#3"%2`!*!)q'-!!!3)#!#"US!($JBF"i! EJ#@)%$4j3bD0Q64Pb"!-L!Z!%`$B!PcB'0#!N!!hEF58N50%!-%J8+!`%G*%L*3 3!3%0h!MR4N#B-QRDa!P!*m%BJ8JU*4KUda3m5K-d!Y%Q$"`3DHD!N!"6*J`C%'r FX-QM0&4"!,%#X#L!!SUF0'lSV!4"jUfGZ9P"0+R$KNiD)h$*c"f$%NiB[f,BP#( *jfbI!&B)EG4)J+3@!!S!Z!&JK)#!*dXX!jLM'F!V!JD'K(%cTJbEM6X"%+JF%%& !!4!#!J%4-!*"fJm!93!!B3`J!#!i"15G'`3"4!(i)5!3(B+Jk!Mr&Ih`$aJ!lYj rr!-(3$cj2rlJ!IMc6cel11[r`AmIhhhkmZ2,lb-2rRYh!!GS*a!r'me'N!"Y!1# Q'fm!q"B3F-)4CaabbL&(((,246GGGGF4#+"fJ26ARhRiRGGHI5Lbjpk*+U*))SN LrKGJ30KY*-*$!$"L@J"q#,486JfFP0*F4+34"KY[R%'3!"bbN93%!'J!N!!&!+4 i"TU6!,JL*3$US+BDDkk44!)!#`"!!`$R3#*!$$13!'4EQ4UJL8J(9k"a'!KLS#3 'A@q!N!$('h@!F-GUG)"!4jpcP&('$l5p")"'A3#!#M!Z(4I3#J"JZT&b4%33`%# CE3S!%3F!-)#TCHB'!4!NF5TJUd**39!!53cKa!JN!@+%&%8BN5Y""`$&K&)-!J$ $ED`3P0Yb!&$`!`m#TD*HHG!+)1f$G-cUK"8"T8+2%eii8BFd48a4440&3#'V4lS -B-Uf!E(`K42YHS*%'rjiJ)SEU2Mc!V3!r2-2#"q!)N-U%U3#3bV-)+((2m5NXJF U8!KabV0&@3c(2bm!N!!+(bYmm3mr,l3`mVm%$I!XHkRi8I,)U94JmEhri*0+*#r cNiS&F!3!5aXeQ`&%cKJ23,-q000$-cZT02+bd[Jb$8N3lIM$cJF3B2`2[3-)mJ) #prU$$Vd!L2"$#rkS!m-(U56$03KFLb!ZZ1)+md4048J"!S0J&B4a!+QidcF")!$ LK$i!1$!i#"dM)-3CJB2`"4421!%0[!!JF3i--*MJ3N%QE-B!#Cp$i%3V!+K!P6q 3!)!`5-p+i$+!"8S#B!-#1!3d3!CQa!X#(V-c!%N68"c441m!H2$ll%UJ)P[Y%La [J3K4%U"%&,86!0m+32MMLK+YH&ml&N(JN`!%3e4Y"4`3b)"0&-L-[$SJkIYM"3L *++%P"QB`-2m,TY-&EV$`#"!Xi!cD#i!*!+%%3Cc"!#!3!JM#ad!Y8H!-#!$"CLJ `3Am3SQIFmaiB"-*"i%f[HM#)`-rmSBFc-1"IPQ+A@JJS2HV*KQSX(!%5!%!#kDf JH[l`4!fVYi)d*-JII"LLE)S)!!2i!a"+*!!6&H""r3%!!fGJ!3R`"3J`+1!&%U" A!)"!3#`S3JQ5k0drj,&&$hS4M'*834R2Q-D!bF1!#$4"q2M3`!G'X)-9E"B'0GL X$K)LLNT)"A,1`!3N3!82C!0(#$8444+N!$P-SQ%!cJ%)%`!!'S#!aL"%!)4T9%d 6*YMN)%!`!'X-`KT3(%)dK!'(!SMJII(MKa3#88YB"')crj!!a[Dkj`SQZ)-"$'J 2hHV`$5P3)3P15!)9i-BYj(`1!3)iMX!iaUl%,E-B@*!!jYlfKMR0lBed"9NG*1" !JQJ!J`4)!)-$d)M"&`J!"&*`!L3)Q!9&U,-@b""$`03"[L!1%PqH#)%3%UG1%%" "RmDF6Ff@f8`U&#'Fdi42$#Le0`5)Lh'b#B8($YFHN!!5i!`Q!!%34)!%#'6J$"k 3!%!%*!!-#!6!$2LB"$*!N!#!+3#"!6(maaXJ#,#!33#+(52!4j0kKZJ"!6i3J!! B#!!"G!J%I[r3Ka!JB0+je8%%Ej!!M5-&%MCGK-d@BC2&#a*!VhkJi!R[D"EC6&F (Lp(,(eSpa9fr9Fd90!B!%d#%2mJK",4pSl$qm-B`rB'0a9*MXFKB,$%fd*J!q'- Bbb`&0+@*K#)%)5#BkaK82kF!@'`'!80e@,0@-E!2J-X&Ra$A&+JJ"5NFB3K)@!) 'TN#(YlMK$2KFc4R+!))KS+%-BeJ$#)+3!#FjC)Y'$$K,!$6A(L%F)3L)!iB)-"" @!*K#"I`MJ!SDS)P!Q+!)*&L#1!)""J%)33Y45-E)B)!"(f"JK!!J"&3`J!%4H'B J$jM1ma`3ML")!!-)5-S"#4#13"bB$J%3m!(1B!%+)&J3!$S$JB9JB34Jf!%)$)F J,-`(!C!!M3N)+!3!(K$L3QJ!!d1B"aCiQ!3"&q!-('""!-J'!`Cm9J!2E!-#YL% *H@j$#PlFKJ6!B!!*[%qqdUQ-!I,BJ'Y)!UYmB-)h(V#e1ZJ"!&-04b0H(!9RC&9 Fb#**!3)#!3dSF!Sl*)M!r#'#1DXJ+8UCX`[!S"Bq`i$222K8&f)$!'D8)!Je-++ 2DU13!)33K#%%Z!!S![$PJ#M('J#UeDd))J3L-1%*4b#)%iJJc@%&4!Y3U"89#'+ '@#e*#+-f03$mX+YH%8343hJ#%ClN%NX84@!rqV@!!P!C![5#0i!!YN"8)"YG)%, B0!*&Xb%4%'8(i"QjX[BdXMhXHH4jB!,a"dPf3S%%h@JM,LN!E`bJL3)e)3a`1F# KDj!!"$HNJ3jMmJ!!!: -------------------------------- cut here -------------------------------- -- Freek "the Pistol Major" Wiedijk Path: uunet!fwi.uva.nl!freek #P:+/ = #+/P?*+/ = i<<*+/P?*+/ = +/i<<**P?*+/ = +/(i<<*P?)*+/ = +/+/(i<<*P?)**
denbeste@bgsuvax.UUCP (William C. DenBesten) (02/09/90)
In article <886@gistdev.gist.com> joe@gistdev.gist.com (Joe Brownlee) writes: > The Mac interface has many features which make it superior to others, but > when it comes to its error handling, I just don't think ID=03 is acceptable. From article <33777@news.Think.COM>, by barmar@think.com (Barry Margolin): > The translations of these bomb id's are things like > "Segment Loader Error". In general, the textual translation would be no > more meaningful to the user than the numeric one. And so what if the user > knows what the error is? There's still nothing he or she can do about it; > it's a bug in the program or OS. I think that the average user would find it helpful if the follwing ones (for example) were reported textually. Memory Corupted id=28 DSStkNHeapHeap Memory Full id=25 DSMemFullErr Application Damaged id=16 DSBadLaunch Application Damaged id=15 DSLoadErr The average user has little use, however, for the difference between an address error, bus error and illegal instruction (ids 1-3). Multiple ids could be mapped to the same message. Of course you would still want to display the id so that those that cared about the distinction still had the information available. As a seperate issue, I would also like to see a trap that programmers could call after any trap that would check all the appropiate return codes and display an alert if the trap returned an error. I end up writing the equivalant of a subset of this trap every time I write a program. I use it when a trap returns an unexpected error. Telling the user about the error is all I can do at this point. I use two parameters for this sort of call. The first is a text message that says where I am and the second is the error number. My dream ReportError() has a textual message with limited scope and a way to tell the computer what to do. The choices would be: Ignore - return from the trap, ignoring the error, Quit Application- call ExitToShell(), Attempt Recovery- call the ResumeProc if the application set it. Retry would be nice but not possible since you have no way of knowing what was just done. As an example, the file manager's text could be limited to choosing one of the following: Disk is full, Disk is damaged Can't open file, Can't read file, Can't write file, File Manager Error. Limiting it this much would probably mean 50 distinct messages, which would occupy probably 1K. Just listing the problem would probably be the usual case. -- William C. DenBesten is denbeste@bgsu.edu or denbesten@bgsuopie.bitnet
isle@eleazar.dartmouth.edu (Ken Hancock) (02/09/90)
In article <5415@bgsuvax.UUCP> denbeste@bgsuvax.UUCP (William C. DenBesten) writes: >I think that the average user would find it helpful if the follwing >ones (for example) were reported textually. > > Memory Corupted id=28 DSStkNHeapHeap Ok, I'll bite. "Uh-oh...the memory in my computer is bad. Does that mean I have to have my Mac repaired." (Don't laugh...that's exactly what some people would thing...) > Memory Full id=25 DSMemFullErr > Application Damaged id=16 DSBadLaunch > Application Damaged id=15 DSLoadErr These errors, as with most, can be generated by other things going wrong so that the System really doesn't know what's going on... in many cases the ID of the System Error is completely irrelevant as to why it happened. Ken -- Ken Hancock '90 | DISCLAIMER: I'm graduating and looking for Consultant | a job, so I'll stand by my words. Computer Resource Center |============================================== Dartmouth College | EMAIL: isle@eleazar.dartmouth.edu
CHRIS.PARSON@f54.n382.z1.FIDONET.ORG (CHRIS PARSON) (02/09/90)
I have the system error DA, and generally don't find it all that usefull. After all, "System Error ID#08" when decoded means "Sysrequest failed at Doomfrazzle" ( or something similar ) so since I didn't DESIGN the thing it adds no more info to my pointy little head. /s -- CHRIS PARSON via cmhGate - Net 226 fido<=>uucp gateway Col, OH UUCP: ...!osu-cis!n8emr!cmhgate!382!54!CHRIS.PARSON INET: CHRIS.PARSON@f54.n382.z1.FIDONET.ORG
lsr@Apple.COM (Larry Rosenstein) (02/10/90)
In article <5415@bgsuvax.UUCP> denbeste@bgsuvax.UUCP (William C. DenBesten) writes: > Memory Corupted id=28 DSStkNHeapHeap > Memory Full id=25 DSMemFullErr > Application Damaged id=16 DSBadLaunch > Application Damaged id=15 DSLoadErr MultiFinder does report Memory Full. id=28 could be a stack overflow caused by a program loop or too much recursion, although the result is definitely corrupted memory. id=16 might make sense, but I think id=15 means that a segment couldn't be loaded, which could be an application memory management error. So it isn't easy to map the id codes to a meaningful error. Larry Rosenstein, Apple Computer, Inc. Object Specialist Internet: lsr@Apple.com UUCP: {nsc, sun}!apple!lsr AppleLink: Rosenstein1
lsr@Apple.COM (Larry Rosenstein) (02/15/90)
In article <2017@rodan.acs.syr.edu> wwtaroli@rodan.acs.syr.edu (Bill Taroli) writes: > >Well, in defense of the Mac OS I would like to mention that I agree that the >issue of using space in the ROMs for static text simply for error messages >is important. Yes, it would be nice to have a cute little message telling you Not to mention that you would need a separate ROM for each localized version of the Macintosh. -- Larry Rosenstein, Object Specialist Apple Computer, Inc. 20525 Mariani Ave, MS 46-B Cupertino, CA 95014 AppleLink:Rosenstein1 domain:lsr@Apple.COM UUCP:{sun,voder,nsc,decwrl}!apple!lsr