[Front] [Prev Chapter] [Next Chapter]

Chapter 5 Error Handling

System Call Error Handling


5.1 System Call Error Handling

Most DR-DOS system calls return error information in the event of the call being unable to complete successfully. The nature of the returned information varies depending on the particular call. “Handle” calls use the carry flag and the AX register to notify the calling program of an error condition, whereas the “FCB” calls use the AL register. For all system calls Extended Error information is available.

5.1.1 “Hhandle” Calls

Application programs can check for error conditions that might occur during handle calls by testing the state of the carry flag. If the carry flag is set then the program can determine the nature of the error condition by examining the contents of the AX register. The following handle calls return error codes in AX:

38H - 43H

44H (subfunctions 0EH and 0FH)

45H - 4BH

4EH, 4FH

56H, 57H

5AH

5CH

65H

67H, 68H

Values for AX and the meaning of those values are shown in Table 5-1.

Code

Error

0

No error

1

Illegal function

2

File not found

3

Path not found

4

No file handles (too many open files)

5

Access denied

6

Illegal file handle

7

Memory control blocks destroyed

8

Insufficient memory

9

Illegal memory block address

10

Invalid environment

11

Illegal format

12

Invalid access code

13

Invalid data

15

Invalid drive specified

16

Removal of current directory attempted

17

Devices do not match

18

No more files

19

Attempted write on protected disk

20

Unit unknown

21

Drive not ready

22

Command unknown

23

CRC error

24

Bad Request Structure Length

25

Seek error

26

Media type unknown

27

Sector not found

28

Printer out of paper

29

Write failure

30

Read failure

31

General failure

32

Sharing violation

33

Lock violation

34

Invalid change of disk

35

File Control Block not available

80

File already exists

82

Cannot create subdirectory

83

Critical error failure

86

Invalid password

5.1.2 FCB Calls

Application programs that use certain FCB calls can also check for error conditions by testing the contents of the AL register. If the contents are set to FFH then an error condition has occurred and the call was not completed successfully.

The following FCB calls provide error status via the AL register:

0FH - 13H

16H, 17H

23H, 29H

2BH, 2DH

5.1.3 Extended Error Information

More information about the precise cause of a notified error condition can be obtained if the application program immediately issues a Get Extended Error system call 59H. This call returns four items of information in the AX, BH, BL and CH registers. The error code is returned in AX. The error Class is returned in BH, the recommended Response in BL and the Resource affected in CH. More information on the error Class, Response and Resource can be found in the description of system call 59H in Chapter 4, DR-DOS System Calls.

5.2 Critical Error Handling

Critical Error Handling is discussed in Section 3.5 INT 24H - Critical Error Exit Address.

An application program can provide its own Critical Error Handling routine. The application’s initialization code should save the INT 24H vector and substitute the start address of the applications error routine as the new INT 24H vector. This error routine will then gain control when an INT 24H occurs as the result of DR-DOS detecting a critical error. On entry to the routine the lower byte of the DI register will contain an error code. Values for these codes are shown in Table 3-3 and match the codes 19 through 31 in Table 5-1.

The error routine can pass control back to DR-DOS in order to obtain a user response to the error. It does this by pushing the Flag register onto the stack and making a FAR Call to the address saved from the INT 24H vector previously. DR-DOS will then issue a request for user response and return to the application error routine at the instruction after the FAR Call.

The error routine may then proceed to deal with the error as befits the needs of the application. To return to the point in the application at which the critical error occurred the routine need only execute an IRET instruction.

The error routine is not obliged to return control to DR-DOS for user response, it can elect to deal with the error itself. If it does so then the routine must also clean up the stack prior to returning control to the application. This involves the application program’s registers being popped from the stack and an IRET instruction being executed. The stack layout on entry to the Critical Error Handler is shown in Figure 3-1.

Critical error handling routines are allowed to issue an INT 21H function 59H system call to obtain extended error information as discussed above. For example it might be the case that a critical error shown as “Drive not ready” by the value in DI was actually caused by a “Sharing violation”. This cause could be determined via the 59H call.


[Front] [Prev Chapter] [Next Chapter]


info@caldera.com
Copyright © 1993, 1997 Caldera, Inc All rights reserved.