Developing Error Handling in COBOL

Developing Error Handling

Handle Errors from the Beginning

Suppose you're developing a new COBOL program or a new enhancement. You're anxious to get something working, even if it is rudimentary. Then you can start adding the bells and whistles. You may be tempted to ignore possible error conditions at first, and add the error handling later.

Resist this temptation.

Error handling is an integral part of any application. Don't just tack it on as an afterthought. Build it into your design, and into your code, from the very beginning.

The time when you first write some code is when you are most aware of the potential error conditions. Later it will be hard to remember what the dangers are.

Many error conditions are most likely to occur during development. That's when you most need to detect and report them.

The need to recover from errors may force you to change your design. If so, it's better to change your design sooner rather than later.

If you don't code for error conditions from the beginning, you may never get back to it -- either because of schedule pressures or because it just isn't much fun.

Test the Error Handling

It's hard enough to fix an error. It's even harder when the code which detects and reports the error turns out to be unreliable. Yet error-handling code is notoriously buggy, mostly because so many programmers don't test it.

Coding error messages is tedious. It's hard to pay close attention, and it's easy to miscode a character literal or a picture clause. Blunders which are hard to spot in the source code may be embarrassingly obvious when you see the actual message issued.

Faulty logic can be even more insidious. If you abend immediately upon detecting an error condition, you probably won't go too far wrong. But if you try to back out gracefully through several layers of code, or if you skip past a non-fatal error and continue processing, there are more opportunities for things to go wrong. Code designed for normal, valid data can do strange and unexpected things when it encounters errors.

Error-handling code is just like any other code: you can't trust it until you've tested it. So test it.

Some error conditions are easy to create. If your program reads an input file, it should test for such things as an empty file, cycle errors, missing header or trailer records, and wrong trailer counts. All you have to do is edit your input file in various ways and make sure your program responds correctly.

Other error conditions are harder to fake -- especially when you're reading complex and mysterious files from other applications. You may be able to insert temporary code to create error conditions artificially:

***** TEMPORARY CODE FOR TESTING RESPONSE TO ERROR IN JK104
     IF INPUT-COUNT > 500
        SET JKKS-FATAL TO TRUE.
***** END TEMPORARY CODE

Some error conditions are more difficult to fake, and unlikely to occur in real life. If you have to jump through a lot of hoops to simulate the error, it may not be worth it. Besides being a lot of work, the creation of the error is likely to be as error-prone as the code for handling it. Just stare at the code, think hard, and cross your fingers.

This last suggestion is, of course, a judgement call. For JOCKEY it is a reasonable approach, if used sparingly. It is not an option for an application which cannot afford to make mistakes -- say, a fly-by-wire avionics system for an F-16.

COBOL Home

COBOL Style Forum