Debugging ABAP like a senior developer

Explanation

The ABAP debugger is one of the strongest in enterprise development, but most developers only use 10% of it. A senior developer picks the right tool for the symptom. **Breakpoints** stop on a line. Use for known code paths. **Watchpoints** stop when a variable changes or meets a condition. Use for "who is clearing this field?". **Session breakpoints** live for your session (SE80). **External breakpoints** trigger for a specific user (SU3 debug user). **Checkpoint groups (SAAB)** let you leave assertions and logs in productive code that fire only when activated for a user — zero cost otherwise. **Background debugging (JDBG)** attaches the debugger to a running background job in SM37 — critical when a bug only reproduces at scale. **Layer-aware debugging** hides framework code (BAdIs, enhancements) so you only step through your own layers. Configure in the debugger settings. **Short dumps (ST22)** are the first stop for any failure. The dump tells you the exception, source line, call stack, variable values at the moment of crash, user, and timestamp. Read it before you touch code.

Code example

" 1) Watchpoint example (set in New Debugger)"    Variable: gs_header-status"    Condition: gs_header-status = 'X'" The debugger halts on the write that sets it to X. " 2) Checkpoint group assertion for production diagnostics (SAAB)DATA(lo_group) = cl_aunit_assert=>get_class( ).ASSERT ID zcp_orders SUBKEY 'pricing'  CONDITION lv_price > 0. " 3) Reading a short dump (ST22)"    - Exception: CX_SY_ZERODIVIDE"    - Source line: 142 in ZCL_PRICING=>CALCULATE_DISCOUNT"    - Variables at crash: lv_qty = 0"    - Called from: SAPMV45A user-exit MV45AFZZ line 87"  → Fix: guard division with IF lv_qty > 0. " 4) Background debugging: in SM37 select job, type JDBG in OK-code

Real project scenario

A month-end job for VAT reporting was crashing at random on production and never in QA. ST22 showed CX_SY_CONVERSION_NO_NUMBER on an amount field. Turning on a checkpoint group for the finance user with a log-point captured the offending record next month-end: a legacy interface was sending an empty string for tax rate. Fixed the source system + added a defensive check. Total dev time: 2 hours. No changes to the productive code path for anyone else.

Common mistakes

- Reading only the exception name in ST22 and ignoring the variable values. - Setting breakpoints in code you *think* runs, without checking with a where-used or a call stack. - Debugging on production without external-breakpoint-user scoping (you can halt other users' sessions). - Forgetting to reset the debugger user in SU3 after finishing. - Using write statements as a debugger — they don't survive background jobs and pollute logs.

Best practices

- Read ST22 fully before touching code. - Prefer watchpoints for "who changes X?" questions. - Use external breakpoints scoped to your user on shared systems. - Add checkpoint groups for durable production diagnostics. - Use JDBG for background job debugging. - Never modify productive code just to debug — always via SAAB / logs.

Interview angle

"Walk me through debugging a background job that fails intermittently." A senior answer names ST22 first, then JDBG for reproduction, then checkpoint groups for future-proof diagnostics, and finishes with root-cause analysis and a regression test. Mentioning layer-aware debugging and watchpoints signals mastery.