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
CRDSS <br />TASK MEMORANDUM 1.05-13 <br />Study of System Integration Issues <br />Error Handling - Guidelines for CRDSS <br />1.0 ISSUE <br />One of the problems encountered by software users involves coming upon an undocumented error <br />when running a program. The software may display a generic message such as "Bad file format" or <br />may display nothing. <br />One way to make the CRDSS more successful is to limit or eliminate errors that cause software to <br />crash. The following issues must therefore be addressed: <br />What types of errors can be detected? <br />? <br />How are errors detected? <br />? <br />What can be done after errors are detected? <br />? <br />How can errors be communicated to the user in a way that the user can then provide <br />? <br />productive feedback to developers? <br />2.0 DISCUSSION/ANALYSIS <br />The UNIX operating system handles errors using an error code variable. Each process that exits <br />(finishes running) generates an integer error code. Different conventions exist for error codes. <br />However, it is most convenient to use the notation that an error code of zero indicates a successful <br />execution, and an error code of non-zero indicates an error. The value of the error code indicates the <br />specific error type. <br />Error codes can be handled at two different program levels. Programs can exit with an error code, <br />and individual routines can return an error code. It is more difficult to determine the error in a <br />program than to determine the error in a single routine unless very detailed error codes are available <br />for the program. <br />Standard UNIX error codes for programs include codes for interrupts and kills, which are actions that <br />the operating system can "inflict" on a program because of a lack of disk space or an action by the <br />user. Error codes for routines can be defined by the developer and may be very simple (e.g., <br />0=success, 1=error) or very detailed (e.g., 100 levels of errors). In general, error codes for low-level <br />routines that perform a simple operation have few error code options while higher-level routines <br />have more complex error-codes. <br />1 <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.