The Wiert Corner – irregular stream of stuff

A few tips.

1. Set breakpoints in these units:
   • System.pas:
     

     procedure _AbstractError;
     begin
       if Assigned(AbstractErrorProc) then
         AbstractErrorProc;
       RunErrorAt(210, ReturnAddress);
     end;

   • System.SysUtils.pas:
     

     procedure AbstractErrorHandler;
     begin
       raise EAbstractError.CreateRes(@SAbstractError);
     end;

2. add a watch for ClassName that has “Allow side effects and function calls” enabled
3. run your code until it breaks or stops (usually in the first method above)
4. double click on each entry in the “Call Stack” pane, and for each entry:
   • set a break point on the call to the method above it in the stack trace
   • note that sometimes this is on the line you arrived, but sometimes one more more lines higher in your code
   • the cause is that the stack trace will show you where your code will RETURN to, not the place it was CALLED FROM.
5. abort your program
6. run your program again
7. on each hit breakpoint, watch the value of ClassName:
   • if it becomes [WayBack] E2003: Undeclared identifier: 'ClassName', then:
     • observe the method directives
     • if it includes static, but it is actually inside a class, then remove the static

Sometimes you cannot perform the last step: class property definitions have to be backed by static class methods.

This usually means you have a bad design anyway: you depend on global/singleton kind of behaviour that is almost impossible to properly test.

A better approach is to have regular object instances for that, then use constructor dependency injection (maybe combined with factory or dependency injection container) to setup the structures of dependencies.

TODO

Create a conference summary on the use of class versus instance methods, and static/regular.

Base materials:

• Workaround for Delphi 2010 compiler error “E2076 This form of method call only allowed for class methods” when it infers a generic parameter type.
• Delphi 2007: reproduction and workaround for “[DCC Error] ….pas(26): F2084 Internal Error: AV21BCE0AC-R00000000-0”
• Delphi class constructors and initialisation order
• Delphi analog to C# ?? null-coalescing operator and Light Table like debugger evaluation
• As Delphi generics are not supported for free functions, wrap them in a record container.
• Delphi: a pattern for a generic factory, this one for components, but can be uses for anything having a base class like a TThread descendant.
• How to convert a Delphi enum or set to a JSON value, with different specific values…
• Delphi: Why is there no class procedure TArray.Sort(Keys: array of T; var Values: array of T; const Comparer: IComparer);
• TInterlockedHelper for Delphi interfaces: Spring.Reactive.pas « The Wiert Corner – irregular stream of stuff
• Class methods in Record vs Class in Delphi 2010 – Stack Overflow
• E2398 Class methods in record types must be static (Delphi) – RAD Studio « The Wiert Corner – irregular stream of stuff
• Delphi static class methods are assignment compatible with plain old function pointers

–jeroen

Still not sure why the RTL code is like this:

procedure TRemotable.SetDataContext(Value: TDataContext);
begin
  if (RemotableDataContext <> nil) and (RemotableDataContext = Self.DataContext) then
  begin
    TDataContext(RemotableDataContext).RemoveObjectToDestroy(Self);
  end;
  FDataContext := Value;
end;

It means that if you ever have to change the DataContext property from the default global RemotableDataContext, it will be removed, but not added to the new DataContext.

When you assign it nil (so you can dump it to JSON, which often is easier to read than XML), and back to the old value, this results in a memory leak:

function TNotificationKeyPortTypeImplementation.prematchChanged(const prematchChangedRequest: prematchChangedRequest): prematchChangedResponse;
var
  DataContext: TDataContext;
begin
  // ...
  DataContext := prematchChangedRequest.DataContext;
  try
    prematchChangedRequest.DataContext := nil; // otherwise the JSON serializer will stackoverflow because DataContext points back to the TRemotable instance.
    Result := Format('prematchChanged: prematchChangedRequest=%s', [TJson.ObjectToJsonString(prematchChangedRequest)]);
  finally
    // `prematchChangedRequest.DataContext := nil` removed `prematchChangedRequest` from `DataContext.FObjsToDestroy`
    DataContext.AddObjectToDestroy(prematchChangedRequest);
    prematchChangedRequest.DataContext := DataContext; // does not add `prematchChangedRequest` to `DataContext.FObjsToDestroy`
  end;
end;

or when you are outside an incoming SOAP call where DataContext might not be assigned at all:

function ToJSON(const Value: TRemotable): string;
var
  DataContext: TDataContext;
  RemotableDataContext: Pointer;
begin
  if Assigned(Value) then
  begin
    DataContext := Value.DataContext;
    try
      Value.DataContext := nil; // otherwise the JSON serializer will stackoverflow because DataContext points back to the TRemotable instance.
      Result := TJson.ObjectToJsonString(Value);
      Result := TRegExSanitiser.ReplaceSecretInText(Result, [rttJSON]);
    finally
      // `Value.DataContext := nil` removed `Value` from `DataContext.FObjsToDestroy`
      if Assigned(DataContext) then
      begin
        RemotableDataContext := GetRemotableDataContext();
        if Assigned(RemotableDataContext) and (RemotableDataContext = DataContext) then
          DataContext.AddObjectToDestroy(Value);
        Value.DataContext := DataContext; // does not add `Value` to `DataContext.FObjsToDestroy`
      end;
    end;
  end
  else
    Result := '';
end;

–jeroen