CX_SY_ZERODIVIDE — CX_SY_ZERODIVIDE runtime exception

Division by zero is not allowed for any numeric ABAP type. Older, non-object-oriented code triggers this as an immediate runtime error (COMPUTE_INT_ZERODIVIDE for integers, COMPUTE_BCD_ZERODIVIDE for packed/decimal). Code written against the class-based exception model, or code that calls a method internally implemented with class-based exceptions, raises CX_SY_ZERODIVIDE instead, an instantiable exception object that a surrounding TRY/CATCH block could theoretically intercept. When no CATCH exists anywhere in the call stack for CX_SY_ZERODIVIDE or one of its superclasses, the runtime still terminates the session, but the dump is classified as UNCAUGHT_EXCEPTION with the exception class named in the header. Functionally the two families are the same defect, arriving through two different ABAP language mechanisms.

If the divisor came from master data, such as a conversion factor, exchange rate, or price field, correct the master record; this is a data fix, not a code change, and does not need a transport. If the divisor came from a missing exchange rate table entry or missing unit conversion entry, maintain the missing entry through the relevant configuration or master data transaction. If the divisor is computed by custom code with no zero check, add a guard clause immediately before the division that either skips the calculation, defaults to a defined fallback value, or raises a meaningful business error instead of letting the runtime divide by zero; this requires an ABAP change and a transport through the normal development and testing cycle. If the division happens inside standard SAP code and the input data is genuinely valid, treat it as a possible program error and raise it with SAP support after confirming no configuration gap explains the zero value, since a code correction to standard objects should not be applied locally without going through the proper channel.

The reflex is to wrap the offending statement in TRY CATCH CX_SY_ZERODIVIDE, catch it, and move on with the result set to zero or left unchanged. This stops the dump but leaves the zero divisor unexplained. The calculation now silently produces a zero unit price, a zero converted amount, or a skipped average, and that wrong number propagates into pricing, costing, or reporting without any error visible to the user. Other divisions elsewhere in the same program, or in a different program reading the same bad master record, are not protected by the local catch and will dump again later, so the underlying data defect resurfaces unpredictably.

Enforce a code review rule that no division statement is written without a preceding check on the divisor, ideally through a shared helper method or macro used consistently across custom developments rather than ad hoc IF statements repeated everywhere. For master data prone to zero values, such as conversion factors and standard prices, add a validation check at data entry so the field cannot be saved as zero when it is used as a divisor downstream. Periodic data quality reports scanning for zero conversion factors, missing exchange rates, or zero standard costs catch the condition before it reaches a production calculation.

Master data and configuration causes, such as a missing exchange rate or a zero conversion factor, belong to the functional team responsible for that master data. Missing validation in custom code belongs to ABAP development. The handover note should include the ST22 trigger location, the exact field identified as the divisor, its value at the time of the dump, and the master record or table entry that supplied it.

Directly related to COMPUTE_INT_ZERODIVIDE and COMPUTE_BCD_ZERODIVIDE, which are the same defect surfacing through non-object-oriented code instead of the class-based exception model. When uncaught, CX_SY_ZERODIVIDE terminates as UNCAUGHT_EXCEPTION, so the two dump categories should be searched together in ST22 history. Explicit RAISE EXCEPTION statements in custom code sometimes wrap or rethrow this exception, which is worth checking when the trigger location points into a custom class rather than a division statement directly.