As described in a previous section (see the ), when the static members of a class type are initialized, ABL executes the static constructor for every class in the class type hierarchy that has static members, starting in order from the root class (top of the hierarchy) to the most derived class of the class type (bottom of the hierarchy). If any static constructor in the hierarchy raises ERROR, ABL considers the load of the entire class type to have failed. If a class type fails to load, ABL does not attempt to load the class again, and all further references to that class type raise a run-time error. This is also true of all subclasses of the super class in the class type hierarchy whose static constructor first raises ERROR. That is, each class type below the class with the failed static constructor also fails to load. However, all super classes above the class whose static constructor raises ERROR do load successfully and these class types are all available to the ABL session. The only way to recover classes that have failed to load because of a static constructor fault is to restart the ABL session and re-run the application after the errors in the failed constructor have been fixed.
A static constructor can raise ERROR in the same way as in an instance constructor—from a RETURN ERROR, an UNDO, THROW, or an unhandled system error that throws an error object out of the constructor block. Any ERROR returned from a static constructor is raised on the statement that caused the static constructor to execute, whether it is the statement that first references a static member or the statement (such as the NEW statement) that first instantiates the class.
