Where any of several fixed formats may apply to a single field, a field-level exit is not the solution. Canadian and British postal codes, for example, each have their own format, both including alphabetic characters that would be invalid in a US ZIP code. Clearly an exit program that merely looks at field data and accepts “any of the above” will miss some errors it should catch.
A field-level exit program controlled by information from other fields is not an acceptable solution to such problems, or indeed to any problem. For example, if an employee is being transferred from New York to London, then the value in the country field when the postal/ZIP exit is called depends on whether the user has updated that field yet. When writing the program, the exit program developer cannot know what order the user will later choose, or even in what order the fields will be presented, since this is user-controlled via Display Order editing in the View. Developers, then, must not rely on data in other fields to control field-level validation.
The general principle is that it is not wise to write a program whose behavior depends on something outside both its program code and the data it was intended to deal with.
A field-level exit program can safely update one field from data in another, for example, converting “MI” in a US state code to “Michigan” in a state name field, provided that:
- either the target field is protected from user data entry, or
- the conversion works both ways
so that the program code guarantees that inconsistent data cannot end up in the two fields.
A field-level exit cannot use data from other fields to control decisions, e.g., to determine which validation it should apply to its target field. At field validation time, all data from other fields must be considered unreliable since the developer cannot know its state. Any code controlled by this would itself be unreliable.