Leaderboard

Raising exceptions in constructor never ever lead to memory leaks. Only if the code in destructor is bad and is not able to clean up partially initialized object instances. such situations may look like raising exception in constructor is at fault, while actually it is the destructor that needs to be fixed in such case.

You're missing TObject.InitInstance which ensures all fields are initialised before the constructor is called. Edit: link for convenience https://docwiki.embarcadero.com/Libraries/Athens/en/System.TObject.InitInstance

Barry Kelly explains it rather good in a comment: https://herbsutter.com/2008/07/25/constructor-exceptions-in-c-c-and-java/

The above code is fine. Free can be called on nil object reference. Testing whether it is assigned before calling Free is redundant.

I am absolutely bewildered. That is absolutely not true. See: Methods (Delphi) - RAD Studio (embarcadero.com) or: https://stackoverflow.com/a/39110161 This is the first time I ever heard something like this.

I stand corrected. What dummzeuch Dalija wrote below is the correct approach. The reason why I raise exceptions before the inherited call is to make sure nothing gets unnecessarily initialized in parent classes. Destructors should handle both scenarios though.

I see no problem with raising an exception in a constructor, provided you write the destructor in a way that can handle a partly constructed instance. Since you can't prevent any system or RTL exception to be raised from within the constructor, you'll have to handle that case anyway. Always keep in mind that an exception in a constructor will cause the destructor being called immediately. So don't do this: constructor TBla.Create; begin inherited; FSomeHelperObject := TSomeClass.Create; end; destructor TBla.Destroy; begin FSomeHelperObject.Free; // <== this might cause an AV if FSomeHelperObject hasn't been assigend inherited; end; But do this instead: destructor TBla.Destroy; begin if Assigned(FSomeHelperObject) then FSomeHelperObject.Free; inherited; end; (Or use FreeAndNil, which basically does the same internally.) You can easily test if your destructor can handle this case by temporarily putting a raise exception.Create('test') as the first statement in your constructor (before even calling inherited Create). I'm sure we are all guilty of writing wrong destructors at some time though.

Raising exceptions in constructor will lead to memory leaks, unless the exception is raised before the inherited call. I don't see a problem with their claims.

I am astounded at both your claim that throwing exceptions in the constructor should generally be avoided.

Give madExcept a try again; It's much easier.

Classes do not need a destructor to be destroyed/freed. A class needs a destructor if it allocated other objects or memory that it should free or there is other cleanup it needs to do before being destroyed. If an object is not being freed, adding a destructor would not fix the issue. Read the comments in FastMM4Options.inc. Specifically: {Set this option to log all errors to a text file in the same folder as the application. Memory errors (with the FullDebugMode option set) will be appended to the log file. Has no effect if "FullDebugMode" is not set.} {$define LogErrorsToFile} {Set this option to log all memory leaks to a text file in the same folder as the application. Memory leak reports (with the FullDebugMode option set) will be appended to the log file. Has no effect if "LogErrorsToFile" and "FullDebugMode" are not also set. Note that usually all leaks are always logged, even if they are "expected" leaks registered through AddExpectedMemoryLeaks. Expected leaks registered by pointer may be excluded through the HideExpectedLeaksRegisteredByPointer option.} {$define LogMemoryLeakDetailToFile} It has been a while since I did this. I found a post on SO for a reminder. Based on that post, copy FastMM4Options.inc to your project folder. Edit the .inc file and remove the period from {.$define FullDebugMode} Do a full build of the project and any leaks should be written to a text file with additional information about the object leaked and when it was allocated.

Vote for MMX Code Explorer in the Essential Delphi Addins survey https://forms.gle/xuFWpSrE5TDdordNA

Hard to believe...