Error handling
Errors during the work on this project may be numerous, and sometimes
many of them may only seem to be errors, so the most important thing is
for Network Administrator to pay attention at the log files produced
by collecting scripts and to physically check any suspicious result!
We'll divide the errors in two groups.
Those are most important.
The problem is that some problems are hard to detect since we have very limited
borders for valid/invalid equipment responses.
We may:
- Run into some equipment being down
This is immediately reflected in the log file!
- Run into foreign tools not working for some reason
This is also immediately reflected in the log file and data tree
is cut on where we cannot advance with information.
- Run into foreign tools working improperly
The bug is in those tools, we should get it fixed as soon as possible.
The engineer should check database tables and see if the data looks
suspicious.
- Run into corrupt or out of date internal databases that yield
incorrect values into data tables
The engineer should check database tables and see if the data looks
suspicious.
- Have a major filesystem problem and get our own table corrupted
Then the engineer should rerun all the connection by hand from the
beginning.
The error proceeding routine is just the write in the log file.
Those problems are easier to track out and fix since they're within
our software.
- If a form was filled incorrectly or the command line was composed wrong.
We just return from the program and print the correct usage to
the user in the accepted UNIX format.
- If no data was detected for the given argument.
We assume a syntax error and report that to the user.
No specific error handling routine was defined.
romm@empire.tau.ac.il
Last modified: Thu Jun 5 06:39:45 1997
