Laserfiche WebLink
Errors can only be detected at the interface between program modules. If a stand-alone program is to <br />be used (e.g., CRSM), it may not be possible to detect specific internal errors in a run, but only the <br />final result of a run (success? or failure?). Consequently, the user interface for such a program will <br />be less fool-proof than programs that have integrated error handling. Existing stand-alone programs <br />may have error-handling procedures in place that can be used to determine errors. For example, the <br />output from such a program could be scanned for error messages which could then be acted on. <br />Also, error messages that are printed to the screen as the program runs could be trapped and <br />interpreted. <br />RTi suggests implementing several general error/warning routines to be used in new code. RTi has <br />used this method successfully for other projects. Routines consist of equivalents to the following <br />(shown in C syntax): <br />#include "error.h" <br />SetWarningFILE ( FILE *warnFILE ) <br />SetWarningLevel ( int warnlevel ) <br />PrintWarning ( int warnlevel, char *routine, char *message ) <br />The first routine sets the pointer to an open file to be used for warning messages (if not called, the <br />default is "stderr"). The second routine sets the warning level for the program (if not called, the <br />default is one, for basic warning messages) by setting a global variable initialized in the " " <br />error.h <br />include file. The third routine is called to print a warning message. The first argument is the <br />warning level for the message (it must be less than or equal to the global warning level for the <br />message to be printed; the second argument is the routine where the message is being printed); the <br />third argument is the message to be printed. Programs developed by RTi generally allow a warning <br />command line argument such as "-warn #" so that the warning level can be set at runtime by <br />developers and users. Error messages are implemented similarly except that no error level is set <br />(these messages are assumed to be fatal). Note that although these routines use global variables, the <br />scope of the variables is confined to the three simple routines and is never directly accessed by other <br />routines. Note also that this type of warning may only be implemented in new code because changes <br />to existing code may require extensive coding. The warning messages could be printed to the screen <br />or could be displayed in an area of a GUI devoted to warning messages. This issue will be studied <br />further in Phase II. <br />Building a complex error-handling procedure for the CRDSS could be an intensive effort, especially <br />if many specific error codes are to be developed and trapped. RTi proposes the early implementation <br />of a mechanism for handling errors, including general error trapping and display features. RTi also <br />proposes limiting error codes to a few common values until more values are needed. This will allow <br />efforts to concentrate on identifying code segments where errors can be detected (including calls to <br />pre-existing code) and trapping those errors. More detailed error handling can be implemented later <br />as more GUI features are implemented. <br />3 <br />A275 05.10.94 1.05-13 Malers <br />