Leaderboard

True thing. Please update the source code from github repo. It's fixed now and there are a few new test cases to cover TObjectList (tests for TObjectList are not complete yet). Thanks

If they all have different names/types, then yes (provided you need getters/setters at all - see dummzeuch's examples). But, if they are all related, eg Name1, Name2, etc then you can use an indexed property instead, eg: Type TEmployee = class private FNames[0..49] : string; Function GetName(Index: Integer) : string; Procedure SetName(Index: Integer; const Value : string); public Property Names[Index: Integer] : string read GetName write SetName; end; implementation {$R *.dfm} Function TEmployee.GetName(Index: Integer): string; begin Result := FNames[Index]; end; Procedure TEmployee.SetName(Index: Integer; const Value: string); begin if Value = '' then raise Exception.Create('Value must not be empty'); FNames[Index] := Value; end; Alternatively, you could do something like this: const EmployeeNameIdx := 0; EmployeeEmailIdx := 1; ... Type TEmployee = class private FValues[0..49] : string; Function GetValue(Index: Integer) : string; Procedure SetValue(Index: Integer; const Value : string); public Property Name : string read GetValue write SetValue index EmployeeNameIdx; Property Email : string read GetValue write SetValue index EmployeeEmailIdx; end; implementation {$R *.dfm} Function TEmployee.GetValue(Index: Integer): string; begin Result := FValues[Index]; end; Procedure TEmployee.SetValue(Index: Integer; const Value: string); begin if Value = '' then raise Exception.Create('Value must not be empty'); FValues[Index] := Value; end; Yes, eg: Type TEmployee = class private ... public type TDetails = record ... end; ... end;

I (relunctantly) agree with ChatGPT on this one - you should not modify the original exception, but instead you should raise a new exception that captures the original exception into the new exception's InnerException property. However, the way that ChatGPT demonstrates this is wrong: Firstly, SysUtils.Exception does not have a public SetInnerException() method. ChatGPT suggests defining a new class, but then doesn't use that class. And that class is just trying to replicate a feature that already exists natively in SysUtils.Exception. Second, ChatGPT's approach does not release ownership of the original Exception, so the try..except will still try to free it when the except block exits, leaving the new Exception holding a dangling InnerException pointer to a now-dead Exception. The correct way to capture an InnerException is to use the SysUtils.Exception.RaiseOuterException() method, eg: try sqhpartyroles.sql := fsqlhandle.buildsql; sqhpartyroles.executesql; except Exception.RaiseOuterException(Exception.CreateFmt('error from sql %s', [sqhpartyroles.sql])); end; (I don't like this syntax, but it is what it is...) Higher up the call chain, you can then catch the new Exception and traverse its InnerException chain if you want to report/log all of the individual error messages, eg procedure MyForm.Application1Exception(Sender: TObject; E: Exception); begin repeat // use E as needed, then... E := E.InnerException; until E = nil; end;