The destructor of a class is a special method that is called automatically by the AVM when a class instance is deleted by garbage collection, by a DELETE OBJECT statement, or class instantiation is halted by a RETURN ERROR or UNDO, THROW. Thus, you never call a destructor directly. The destructor of a class has the same name as the class name. Unlike ordinary methods, a destructor definition is identified by the DESTRUCTOR statement. Destructors have no return type, are always PUBLIC, and cannot have any parameters. Destructors also are instance members. Note that there is no static destructor.
A class is not required to have a destructor. If a class has not defined a destructor for the class, ABL provides a default destructor for the class.
For each class instance that you delete, its destructor is responsible for deleting any resources allocated during the execution of that class instance. Deleting the class instance automatically deletes all dynamic handle-based objects that are created in any default unnamed widget pool that is specified for the class. (For more information, see Using widgetpools.) Otherwise, you can code the destructor to explicitly delete resources that have otherwise been created by the class instance.
The DELETE OBJECT statement can already be used to delete dynamic visual and data objects as well as persistent procedure instances. What is different about classes with a destructor is that a class is given an opportunity to do necessary cleanup work when it is deleted. The value of the destructor is that it is executed automatically when the class instance is terminated using the DELETE OBJECT statement or as a result of garbage collection.
At run time, the AVM frees all allocated memory associated with the object reference when it executes the DELETE OBJECT statement. Before doing this, the AVM invokes the destructor for each class in the object’s class hierarchy, if one has been defined.
When the client session is shut down, the AVM deletes all remaining class instances, invokes the destructor for each class in the object’s class hierarchy, and frees all resources associated with them. In addition, the AVM automatically deletes any ABL-related resources, such as persistent procedure, visual objects, and data objects.
If a destructor fails to clean up the resources that were allocated for the object, there is no mechanism for it to inform the caller (for example, a DELETE OBJECT statement) that it failed. Also, you can use a a RETURN ERROR or an UNDO, THROW in a destructor, but it is illegal to return an ERROR condition from the destructor to the caller.
