Delphi Runtime Error 210 — What It Means & How to Fix It

What Does This Error Mean?

Runtime Error 210 means your code called a method or accessed a property on an object reference that has never been initialized — it is nil. In Delphi, declaring a variable of a class type (var MyObj: TMyClass) does not create the object. You must explicitly call MyObj := TMyClass.Create before using it. This error is the Delphi-specific form of the classic 'null reference' bug.

Affected Models

Delphi 12 Athens
Delphi 11 Alexandria
Delphi 10.4 Sydney
Delphi 10.3 Rio
Delphi 10.2 Tokyo

Common Causes

Declaring a class variable (var MyObj: TMyClass) without calling Create before using it
A factory function or constructor returning nil because an error occurred, and the caller not checking the result
Using an object after it has been freed — the variable still holds the old address but the object no longer exists
An object field declared in a class that is never initialized in the constructor
Conditional creation logic where the object is only created in some code paths but used unconditionally later

How to Fix It

In the debugger, locate the exact line that causes Runtime Error 210. Hover over the object variable on that line — if it shows nil or 0x00000000, the object was never created or was already freed.

The Delphi debugger shows the current value of variables when you hover over them during a debug session. A nil object variable will show as nil or 0.
Ensure the object is created before first use. Add a Create call: MyObj := TMyClass.Create; Do this before any method or property access. If the object should persist, create it in the owning form's constructor (override constructor or FormCreate event).

Declaring var MyObj: TMyClass only reserves space for a pointer. The actual object does not exist until Create is called.
Use the Assigned() function to guard against nil before calling methods on an object that might not exist: if Assigned(MyObj) then MyObj.DoSomething;

Assigned(X) is equivalent to X <> nil, but is more explicit about intent and works correctly for both objects and procedure pointers.
After freeing an object, immediately nil the variable using FreeAndNil(). This prevents accidental use-after-free, which can also cause Runtime Error 210 or a silent access violation.

FreeAndNil(MyObj) frees the object and sets MyObj := nil in one step, making any subsequent Assigned() check return False.
Review class constructors to ensure every field that is itself an object is created before first use. Fields of class type declared in a TObject descendant are nil by default — they do not self-initialize.

Common pattern for a form with a child object: constructor TMyForm.Create(AOwner: TComponent); begin inherited; FHelper := THelper.Create; end;

When to Call a Professional

Runtime Error 210 is always a code defect — the fix is to ensure the object is created before use. Use Assigned() to check whether an object reference is non-nil before calling methods on it. In the debugger, hover over the variable to confirm it shows nil at the point of the crash.

Frequently Asked Questions

Why does declaring a class variable not automatically create the object in Delphi?

In Delphi, class variables hold a reference (a pointer) to an object in memory. Declaring the variable allocates space for the pointer only — it defaults to nil. This design gives you explicit control over when objects are created and destroyed, which is important for performance and for managing object lifetimes correctly. You must call Create to allocate the object and initialize its fields.

What is the difference between Runtime Error 210 and a general access violation (Runtime Error 216)?

Runtime Error 210 is raised by Delphi's own runtime when it detects a call to a virtual method on a nil object reference, before the actual memory access occurs. Runtime Error 216 is a General Protection Fault raised by the operating system when code actually attempts to read or write to an unmapped memory address. Runtime Error 210 is caught earlier and has a clearer meaning — 216 is a lower-level OS-reported crash.

Can calling a non-virtual method on a nil object sometimes work without crashing?

Yes — this is a dangerous trap in Delphi. A non-virtual method call is resolved at compile time and does not dereference the object pointer until the method body accesses a field or calls a virtual method. So a method that does not touch any fields may run 'successfully' on a nil object without crashing immediately. This gives a false sense that everything is fine, but the nil bug is still there waiting to surface unpredictably.