Run-time Errors:
 
 
 ** Yeah, it's real easy for a user to say "I don't want to see runtime
  errors", isn't it? :-)  No program is bug-free, and regardless of how
  well you've read the TP/BP manual, there is no way to check for all
  possible runtime errors...

Find yourself a unit that will trap those errors. While you will still get
runtime errors, you can create your programs to not only log the error messages
but also give the user a little better indication of what error has been
produced. Rather than 'RUNTIME ERROR #XXX AT xxxx:xxxx" you can report "FILE NOT
FOUND". Few people will know what a runtime error message is. What they do know
is that your program bombed. Knowing the program bombed because it couldn't find
a file is much more informative.

For Pascal there are a number of units in the SWAG archives that will do all
this. All you need to do is set the program up as the first unit in the USES
section, then tell it what file to use to record the error messages to if you
want them logged. It doesn't get much simpler than that.

Error logging is the biggest advantage. Makes it a lot easier to track a bug
down when someone can show you EXACTLY what error was reported, rather than what
they 'think' the message said.

Other opinions!!!!
 
 Run-time errors don't occur because of the multiplex of different systems.  
 It's not the computer's fault.  Lengthy, quality testing can find every 
 run-time error.

>> I disagree with you.  Systems DO have some say in whether or not you get a 
runtime error.  Lack of memory..etc.. are system-related memory problems.
However, the majority of them can be found.  Not All.

>> Runtime errors don't happen because somebody runs a
different version of DOS. They are usually program's runtime
support system reaction to something not anticipated by the
programmer. The problem with this is that the program just
terminates and doesn't tell me anything helpful.

>>But you just answered why it isn't possible to fix all
runtime errors.  It's because the programmer didn't anticipate
that type of error happening.

        However, if the program just terminates, then it's
clear that the 'halt' command was executed without explanations.
Then the programmer should've clearly added some 'written'
explanations.

>> ok, suppose it's 002: file not found. now, the question is:
what file was that? and what should I do about it?

>>That's a good point..  I do agree with you that those
    'file not found' errors are frustrating, as it's not clear
    which file wasn't found.  ;)

>>Yes, runtime errors happen because the programmer didn't think of something.
But thinking of things like that is what programming is all about. Every
programmer should anticipate that his program will have to work in most
unfriendly conditions: with about 120K for both code and data, 0K of EMS/XMS 
and almost zero disk space. and most of all, it will be used by people other 
than the author. <G>

Actually, in a case of a runtime error the "halt"/"exit" command is executed 
by the runtime system, NOT the program itself. compiler manuals recommend to 
turn off runtime error checking for delivered products.

maybe the authors should include a list of runtime errors with their program
documentation? <G>




Subj : DDIGM beta                                                            
ÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄÄ

Attention IGM authors:
Seeing that so many people are having problems getting their IGM to run,
especially with direct and non-standard ports I decided to make a
special kit from DDplus (the same TP kit LORD uses) for creating IGMs.
If you have an IGM written in Turbo Pascal, in particular with DDPlus
this can be an easy transition (provided you know TP).

This kit is beta so it is not for general release. This is not intended
as a way for someone who doesn't know programming to make an IGM.  But,
if you currently have a buggy TP IGM out there and want to possibly fix
it then try out DDIGM.

Oh, and it has some other features:
1. Includes an example igm program (ddigmain) with internode chat.
2. Players.dat file access.
3. Can be setup and run in it's own directory.
4. Can be run standalone local for testing.
5. Enhanced Lord colors that also does background colors.
6. Also, works with direct comports (both standard and non-standard) on
   Lord 3.26a. But, no direct comm I know of runs on 3.50-3.52.

Current version name DDIGM100.zip.

For an example of an IGM written with this kit try LordChat. A FREE
multinode action word chat IGM.

Steve Lorenz - The Officers' Club BBS (818) 249-8579
þ