EAbstractError
Delphi Programming Language
Severity: CriticalWhat Does This Error Mean?
EAbstractError is raised when code calls an abstract virtual method that has never been overridden. In Delphi, abstract methods are declared with the abstract directive — they have no implementation in the base class. If you instantiate the base class directly (instead of a subclass that overrides the method), and then call the abstract method, Delphi raises EAbstractError.
Affected Models
- Delphi 10.4 Sydney
- Delphi 11 Alexandria
- Delphi 12 Athens
- Embarcadero RAD Studio
- Free Pascal / Lazarus
Common Causes
- Instantiating an abstract base class directly instead of a concrete subclass
- A subclass exists but forgot to override one or more abstract methods from the parent
- A factory function returned the wrong class type, giving back the abstract base instead of a concrete subclass
- Calling an abstract method during the constructor of the base class before the subclass has overridden it
- An interface implementation class does not implement all required methods
How to Fix It
-
Enable compiler warnings in Project → Options → Compiler → Warnings. Look for the warning 'W1029 Constructing instance of class with abstract method' — this tells you at compile time where the problem is.
This warning is the earliest possible detection. Treat all compiler warnings as errors during development.
-
Find the class hierarchy. Identify which abstract method was called (the call stack in the debugger shows it). Find the base class that declares it as abstract.
The method will be declared like: procedure DoSomething; virtual; abstract; — the abstract keyword means no implementation exists here.
-
Override the abstract method in your concrete subclass. Add the method signature to the class declaration and implement the method body.
In Delphi, override is the keyword: procedure DoSomething; override; — without override, the method is not connected to the virtual dispatch table.
-
If the base class should never be instantiated directly, make its constructor protected or add a guard: raise EAbstractError.Create('Use a concrete subclass') in the constructor body.
Some frameworks use this technique to enforce the factory pattern — you must go through a factory method to get an instance.
-
Review all factory functions and class references (TClass variables) that create instances. Ensure they always produce a concrete class, not the abstract base.
Metaclass variables (TMyBaseClass) can hold a reference to any subclass. Verify the assignment always sets a non-abstract class.
When to Call a Professional
EAbstractError always indicates a design or programming error — it should never occur in correct production code. The Delphi compiler warns 'Constructing instance of class with abstract method' when you try to instantiate an abstract class — enable and pay attention to compiler warnings. The fix is always to either implement the abstract method in the subclass or prevent direct instantiation of the base class.
Frequently Asked Questions
Why does Delphi allow instantiating an abstract class if it is going to fail?
Delphi issues a compiler warning but does not make it an error — it allows the instantiation because the class is technically complete enough to create an object. The runtime detects the problem only when the abstract method is actually called. To make the compiler treat this as an error, use {$WARN CONSTRUCTING_ABSTRACT ERROR} in your project.
Can EAbstractError happen in correctly shipped production software?
It should not. EAbstractError always means a programming bug — either an abstract class was instantiated or an override was forgotten. If it appears in production, it means the bug was not caught during testing. Enabling the compiler warning and having thorough test coverage prevents this.
Is EAbstractError catchable with try/except?
Yes, you can catch it, but catching it does not fix the underlying design problem. In a try/except handler you can log the error and prevent a crash, but the operation the user tried to perform has still failed. The correct response is always to fix the missing method override in the source code.