Using Try and Finally to Help Prevent Memory Leaks During Dynamic Object Creation in Delphi

If the object created during runtime is not freed properly, the memory remains occupied but the application can longer free it, leading to an access violation error. A memory leak may go on filling the available memory, degrading the performance considerably even if it doesn't actually crash the system. But let's first take a look at how a component is created and destroyed during runtime in Delphi. You can call a constructor method with or without parameters to create its instance and later free it explicitly. In the code that follows I am creating a local variable as an object reference to an instance of TTable, performing database transaction and freeing it.

var
   Tbl1:TTable;

begin
   Tbl1:=TTable.Create(nil);
   Tbl1.Databasename:='EmployeesDB';
   Tbl1.TableName:='Employees';
   Tbl1.Open;
   Tbl1.Insert;
   Tbl1.FieldByName('Employee_Name').AsString:=EditEmpName.Text;
   Tbl1.Post;
   Tbl1.Free;
end;

This works fine as long as none of the statements occurring between the Create and the Free methods cause error. If they do the process terminates, but the memory allocated to Tbl1 is not freed and we have a resource leak at hand. Memory leaks in Delphi can turn into a real nightmare; you can take my word on it.

This situation can be avoided, however, by putting the code in "try/finally" blocks. A try/finally statement consists of two blocks of statements. The first "try" block consists of statements which may raise exceptions, while the finally block contains statements that should be executed regardless of whether the statements in the try block raised errors or not. You can put the database transaction code in the try block and free the object in the finally block so that it is executed even if the database transaction ends in an error.