Delphi E2261 — What It Means & How to Fix It

What Does This Error Mean?

Delphi error E2261 means you tried to raise an object as an exception, but the class you used does not descend from Exception. In Delphi, only classes that inherit from the Exception class (or its descendants) can be raised with the raise keyword. The fix is to either inherit your error class from Exception, or raise a standard Exception with your error information.

Affected Models

Delphi 10.4 Sydney
Delphi 11 Alexandria
Delphi 12 Athens
Embarcadero RAD Studio
Free Pascal / Lazarus

Common Causes

Attempting to raise a plain TObject or TComponent instance as an exception
Raising a custom class that was not declared as inheriting from Exception
Copying code from another language (like C# or Java) where any object can be thrown
A type alias or forward declaration that lost the Exception ancestry
Raising a record or value type instead of a class

How to Fix It

Find the class you are trying to raise. Check its declaration — does it say class(Exception) or class(TObject)? The base class must be Exception or a class that descends from it.

Exception is declared in SysUtils. You must include SysUtils in your uses clause to access it.
Change the class declaration to inherit from Exception: TMyError = class(Exception). Re-run the build — E2261 should be gone.

All standard Delphi exception classes (EAccessViolation, EDivByZero, etc.) inherit from Exception through a hierarchy. Your custom exceptions should too.
If you want to attach extra data to your exception, add properties to your Exception subclass: TMyError = class(Exception) private FCode: Integer; public constructor Create(AMessage: string; ACode: Integer); property Code: Integer read FCode; end;

Exception subclasses with custom fields are the standard Delphi way to carry extra error information.
For quick one-off exceptions, use the standard Exception class directly: raise Exception.Create('Something went wrong'); — no custom class needed.

Reserve custom exception classes for errors that callers need to catch specifically. Generic logic errors can use Exception.Create directly.
If translating code from another language where non-Exception objects are thrown, replace each raise with a proper Exception subclass. Map the original error type to an appropriate Exception subclass.

Delphi does not support raising arbitrary objects. Every exception must be an Exception descendant.

When to Call a Professional

E2261 is a compile-time error that prevents the build. Delphi's exception model requires all raisable types to descend from the Exception class, which is defined in SysUtils. This is stricter than some other languages but ensures that all exceptions have a common interface (Message, StackTrace, etc.).

Frequently Asked Questions

Why must exceptions in Delphi inherit from Exception?

The Exception base class provides the Message property and the infrastructure for exception handling in Delphi's try/except/finally system. Without this common base, the except block would have no guaranteed interface to work with. Delphi's design is strict here to ensure all exceptions can be caught, inspected, and reported consistently.

Can I add a numeric error code to a Delphi exception?

Yes. Create a subclass with an additional property: TAppError = class(Exception) public Code: Integer; end; In the constructor, set the code: FCode := ACode; inherited Create(AMessage); The caller can then catch TAppError and read Code to take specific action based on the error number.

Should I create a custom exception class for every error type in my application?

No. Create custom exception classes only when the caller needs to distinguish between error types and take different actions. If the caller always shows a message and continues, a plain Exception.Create is enough. Over-designing an exception hierarchy adds complexity without benefit. A good rule: one custom exception class per module or layer of your application is usually sufficient.