Path: utzoo!utgpu!news-server.csri.toronto.edu!cs.utexas.edu!sun-barr!olivea!decwrl!deccrl!bloom-beacon!eru!hagbard!sunic!mcsun!ukc!icdoc!tgould!dbh From: dbh@doc.ic.ac.uk (Denis Howe) Newsgroups: comp.sys.acorn Subject: Re: internal error 5 Message-ID: Date: 28 Jan 91 17:11:07 GMT Sender: news@doc.ic.ac.uk Distribution: comp Organization: Dept. of Computing, Imperial College, London, UK Lines: 23 In article <4803@acorn.co.uk> pcolmer@acorn.co.uk (Philip Colmer) writes: > In article <1991Jan26.150347.10596@ugle.unit.no> dhmyrdal@solan.unit.no (Dag H}kon Myrdal) writes: > >>It seems to be Acorn's idea that an abstract, non-informing error-message >>like "Internal error #" is better (more professional?) than simply >>stating what the problem seemed to be!!! > >Basically, it comes down to the fact that once a program has suffered a >really bad problem, there isn't an awful lot that can be done to recover >from it, so it is best to exit cleanly and not run the risk of stamping on >anything else. Exit cleanly, yes. Exit cryptically, no! For example, when running Basic programs from the desktop, it's annoying not to be told the program line number where the error occured. The theory is presumably that the inexperienced user would be confused by too much information but as long as he can distinguish between errors he has caused and errors in the program the error message should be as informative as possible. -- Denis Howe Aliens ate my signature file.