CX_SY_CREATE_OBJECT_ERROR — CREATE OBJECT statement fails to instantiate a class

This dump fires at the point a CREATE OBJECT statement executes, before any constructor logic has a chance to run business rules. ABAP has already failed to resolve the statement into a valid object reference. The exception is structural: the runtime cannot find the class, cannot access it, or is not allowed to build an instance of it as requested. This is distinct from a constructor that runs successfully but then raises its own exception class for a business reason – that case propagates the constructor’s own exception, not CX_SY_CREATE_OBJECT_ERROR. Seeing this specific class in ST22 means the failure happened in the instantiation mechanism itself, most often because the class name was supplied dynamically and turned out to be wrong, or because the static class referenced in the code cannot be created the way the statement asked.

If the class name was resolved dynamically from a customizing or configuration table, correct or remove the invalid entry - this is a configuration change and, if done in a controlled landscape, needs a change request to move the corrected entry through the transport path. If the class is abstract, fix the calling code to instantiate the correct concrete subclass, or route the call through the existing factory method if one exists - this is an ABAP code change requiring a transport. If the constructor is private or protected, replace the direct CREATE OBJECT with the intended static factory or singleton accessor method - again a code change. If the class is simply missing or inactive because of an incomplete transport, import the missing request or activate the class; this is a Basis/transport action, not a code fix, and should not be patched around in the calling program. If the mismatch is caused by an add-on or business function not being active, confirm licensing and activation with the functional team before assuming it is a technical defect.

The reflex fix is to wrap the CREATE OBJECT in TRY / CATCH CX_SY_CREATE_OBJECT_ERROR (or worse, CATCH CX_ROOT) and simply log or ignore it, letting execution continue without the object. This suppresses the dump but leaves the underlying configuration or code defect in place, and the downstream process silently does nothing useful - no output created, no follow-on document posted, no workflow step executed - with no visible error for anyone to chase. Catching CX_ROOT is worse still because it also swallows unrelated exceptions raised later in the same block, masking a different bug entirely.

Where a class name is stored in a configuration table and read dynamically, validate it at maintenance time rather than at runtime - restrict the input help to existing, non-abstract, publicly instantiable classes, or run an existence check with the class description services before the CREATE OBJECT executes and raise a clear configuration error instead of letting the runtime dump. For factory or singleton patterns, keep the constructor private and document the required entry point so developers are not tempted to bypass it with a direct CREATE OBJECT.

Default owner is ABAP development, since the fix is almost always a code change or a class transport. If the class name comes from functional customizing (BAdI implementation, output determination, workflow), the functional consultant who maintains that configuration owns the correction of the entry. The handover note should state the class name involved, the source of the dynamic name if applicable, the system and client where it failed, and whether the class exists at all in that system.

CX_SY_MOVE_CAST_ERROR appears in the same neighborhood when a reference is cast to an incompatible type rather than failing at creation. CX_SY_OBJECTS_OBJREF_NOT_ASSIGNED covers the case where a reference was never assigned at all, which is often confused with a failed CREATE OBJECT. CX_SY_UNCAUGHT_EXCEPTION shows up when this exception is not caught anywhere in the call stack. CX_SY_CALL_FUNCTION_NOT_FOUND follows the same dynamic-name-resolution pattern for function modules instead of classes and is worth checking if the same configuration table drives both.