Delphi-Quellcode:
procedure TTest.PayPalTest;
var
Soap: THTTPRIO;
PayPal: PayPalAPIInterface;
Sec: RequesterCredentials;
Request: RefundTransactionReq;
Response: RefundTransactionResponse;
begin
Soap := THTTPRIO.Create(
nil);
try
//...
Request := RefundTransactionReq.Create;
Request.RefundTransactionRequest := RefundTransactionRequest.Create;
Response := PayPal.RefundTransaction(Request);
finally
FreeAndNil(Response);
FreeAndNil(Request);
CoUnInitialize;
end;
end;
Ohne mich da jetzt reinlesen zu müssen, kann ich dir sagen, dass so eine Architektur, wie du sie geschrieben hast, nicht gerade sicher ist. Du kannst/solltest keine Objekte im "finally" freigeben, die du im "try" erst erzeugt hast. Das kann ganz leicht zu Zugriffsverletzungen führen. Und zwar beispielsweise immer dann, wenn im Konstruktor ein Fehler passiert, der nicht abgefangen wird. Der richtige Weg wäre 1. das Objekt erzeugen, dann in "try" damit arbeiten und später im "finally" freigeben. Dann bist du immer auf der sicheren Seite. Außerdem: Gewöhne dir an, alle Typen mit einem "T" und alle Interfaces mit einem "I" im Namen zu beginnen. Das macht es einfacher, sie zu identifizieren und von Standardtypen auseinander zu halten. Ich weiß jetzt nämlich zB nicht sicher, was bei dir ein Interface und was ein Klassen/Recordtypen hat. Das ließe sich leicht vermeiden. Ich sehe außerdem, dass du "Request.RefundTransactionRequest" erzeugst, aber nirgendwo freigibst. Ist es ein Interfaced-Typ mit Refcounting? Falls nein: Diesen MUSST du natürlich auch wieder freigeben, es reicht nicht, nur das Mutterobjekt freizugeben.