My WebLink
|
Help
|
About
|
Sign Out
Home
Browse
Search
CRDSS_Task1_05-13_ErrorHandling
CWCB
>
Decision Support Systems
>
DayForward
>
CRDSS_Task1_05-13_ErrorHandling
Metadata
Thumbnails
Annotations
Entry Properties
Last modified
9/25/2011 10:18:53 AM
Creation date
5/30/2008 2:37:59 PM
Metadata
Fields
Template:
Decision Support Systems
Title
CRDSS Task 1.05-13 - Study of System Integration Issues Error Handling - Guidelines for CRDSS
Description
This memorandum discusses technical issues behind handling errors generated by CRDSS products.
Decision Support - Doc Type
Task Memorandum
Date
5/10/1994
DSS Category
DMI Utilities
DSS
Colorado River
Basin
Colorado Mainstem
Contract/PO #
C153658, C153727, C153752
Grant Type
Non-Reimbursable
Bill Number
SB92-87, HB93-1273, SB94-029, HB95-1155, SB96-153, HB97-008
Prepared By
Riverside Technology inc.
There are no annotations on this page.
Document management portal powered by Laserfiche WebLink 9 © 1998-2015
Laserfiche.
All rights reserved.
/
4
PDF
Print
Pages to print
Enter page numbers and/or page ranges separated by commas. For example, 1,3,5-12.
After downloading, print the document using a PDF reader (e.g. Adobe Reader).
Show annotations
View images
View plain text
Error codes are typically coded in a C include file using statements, e.g.: <br /> #define <br />#defineSUCCESS0 <br />#defineFAILURE1 <br />#defineCANT_READ_FILE2 <br />#defineCANT_WRITE_FILE3 <br />Note that a generic list of error codes can be developed. Different routines can use appropriate error <br />codes from the list. These error codes should be documented in the DIAGNOSTIC section of man <br />pages for the routines (see Task Memorandum 1.05-11). The return codes from routines are then <br />evaluated as follows (using C code): <br />intstatus; <br />status = CallRoutine ( ... ); <br />if ( status == SUCCESS ) { <br />} <br />else if ( status == CANT_READ_FILE ) { <br />/* unable to read the file */ <br />} <br />else {/* There was another error */ <br />} <br />Using zero for does lead to the somewhat confusing code: <br />SUCCESS <br />if ( !status ) { <br />/* success */ <br />} <br />else {/* error */ <br />} <br />Here the C operator is the logical negation operator and the if statement asks "if not status" (e.g., <br />! <br />"if status does not have a non-zero value"). However, if the code is confusing, then the full <br />implementation shown in the full example should be used. <br />Errors can have different severity. Typically, errors are classified as either "fatal" or "non-fatal." <br />Fatal errors generally result in the program not being able to continue; however, the user may be able <br />to reinitiate an analysis by specifying new information. An example of a fatal error is when a <br />program whose purpose is to solve a system of equations cannot do so because the system is <br />singular. Non-fatal errors are those which impede the progress of a program but allow the program <br />to continue, perhaps with additional user input. For example, a program may not be able to read the <br />input file for an analysis because the user has mistyped the name of the input file. In this situation, <br />the program should print a warning and the user would have the option of entering a new input file. <br />Non-fatal errors are typically referred to as warnings. <br />Errors can be "trapped" and appropriate actions taken. This requires that the error codes for the <br />program or routine be documented and that the higher-level code trapping the errors perform checks <br />on the return codes from lower-level routines. It also requires locations in code where errors may <br />occur (e.g., dividing by zero) are anticipated and checked. Actions may consist of prompting the <br />user to re-enter data or select a different program option. <br />2 <br />A275 05.10.94 1.05-13 Malers <br />
The URL can be used to link to this page
Your browser does not support the video tag.