Leaderboard

try Foo := TFooBar.Create; ... finally Foo.Free; end; Consider the above. Suppose that TFooBar.Create raises an exception. In that case the finally block is executed, and `Foo.Free` is called on an uninitialised variable (Foo). That leads to undefined behaviour. So the correct pattern is Foo := TFooBar.Create; try ... finally Foo.Free; end; Here, if TFooBar.Create raises an exception, the try is never reached, and so the finally block never executes. Now another pattern was also mentioned Foo := nil; try Foo := TFooBar.Create; ... finally Foo.Free; end; This is also valid, because Foo is initialised before the try executes. And so in case of constructor exception we would call Free on a nil reference which is fine. However, this pattern is pointless and should be avoided in the scenario here where there is just a single object. It is useful sometimes if there are multiple objects and you want to avoid deep nesting. A better example of using this pattern is if the object is created conditionally: Foo := nil; try if someTest then begin Foo := TFooBar.Create; ... end; ... finally Foo.Free; end;

I had a similar problem decades ago with a French payment processor called "Yaskifo". Small startup which offered best prices at that time. But with wrong management of their internal costs, and which were sued by French banks at that time... Yaskifo owned me thousands of Euros, which I never saw back... Once their company was bankrupted, all customers could just weep. I don't know anything about FastSpring, but in doubt, my advice would be to switch to a bigger and safer alternative - at least joined to some well known bank or company. Even if their fee is higher.

What I've done now is created an internal calculated float field 'Exact2', converting the hyphen and Null values to 99, and set the IndexFieldNames to 'Exact2' and the SetRange now works correctly.

It depends. Do either this: Foo := TFooBar.Create; try ... finally Foo.Free; end; or this: Foo := nil; try Foo := TFooBar.Create; ... finally Foo.Free; end;

Must be very unproductive and frustrating the way you handle things - it is known that humans are terrible at context switching.

With boolean short circuit you probably won't get B and C executed if A returns True. I doubt that order of execution in a condition is specified, optimizer could swap them. Moreover, do you really intend to return true if just some of the functions return true? My option: res := A; Result := Result or res; ...