You can write code. But can you fix it when it breaks? That is the real test of an ABAP developer. In every project you will join, you will spend more time debugging existing code than writing new code. And when your own code fails, you need to handle errors gracefully — not let the program dump on the user’s screen.

This chapter gives you the two essential survival skills every ABAP developer needs: debugging (finding what went wrong) and error handling (making sure it never dumps on the user).

🎯 What You Will Learn in This Chapter

• How to activate and use the ABAP Debugger
• How to set breakpoints and watchpoints
• The difference between session and external breakpoints
• How to read a short dump and find the root cause
• How to handle errors with TRY / CATCH and class-based exceptions
• All six MESSAGE types (A, E, W, I, S, X) and when to use each
• How to debug a background job (the tricky one)
• Introduction to ST05 and SAT for performance analysis

🐞 What is Debugging?

Debugging is the process of pausing a running program, inspecting its state, and stepping through it line by line to find the source of a problem.

Imagine reading a 500-page book and you need to know what a specific character says on page 247. You would not read all 500 pages. You would skip to page 247 and read carefully from there. Debugging works the same way — you jump to the exact line where the problem occurs and watch what happens.

🛠 The ABAP Debugger — Two Flavors

SAP provides two debuggers:

How to activate the debugger

🎮 Debugger Controls — The Buttons That Matter

Once the debugger opens, you will see a toolbar. These are the buttons you will use most:

🎯 Breakpoints vs Watchpoints

These are the two core debugging tools. Understanding the difference will save you hours.

Breakpoints — pause at a specific line

A breakpoint stops the program when execution reaches a specific line of code. You set it where you suspect the bug is.

" Set a breakpoint here to inspect before this line runs
SELECT * FROM scarr INTO TABLE @DATA(lt_scarr).
BREAK-POINT.  " Program pauses here
LOOP AT lt_scarr INTO DATA(ls_scarr).
  WRITE ls_scarr-carrname.
ENDLOOP.

Watchpoints — pause when a variable changes

A watchpoint does not care about the line — it stops when a specific variable changes value. This is incredibly powerful for tracking down where data gets corrupted.

Session vs External breakpoints

💥 Reading a Short Dump

A short dump is what SAP calls a runtime error. It happens when your program does something illegal — dividing by zero, accessing a non-existent table row, referencing a null object.

When a dump occurs, SAP shows the user a screen with technical details. As a developer, you read those details to find the cause.

Where to find dumps

• ST22 — Transaction to view all dumps in the system
• Runtime error screen — The dump itself shows the error text and where it occurred

Common dump types and their causes

📢 MESSAGE Types — A, E, W, I, S, X

Every message in ABAP has a type. The type determines how the message appears and what happens after it.

MESSAGE statement syntax

" Using a message from message class ZMSG
MESSAGE e001(zmsg).                " Error type, message 001

" With dynamic text
MESSAGE i001(zmsg) WITH lv_name.

" Inline syntax (modern)
MESSAGE |Error: { lv_msg }| TYPE 'E'.

" Check message type in code
IF sy-subrc <> 0.
  MESSAGE 'Record not found' TYPE 'E'.
ENDIF.

🛡 Exception Handling — TRY / CATCH

Exception handling is the art of catching errors before they crash the program. ABAP has two approaches: classic exceptions (older) and class-based exceptions (modern, recommended).

Class-based exceptions — TRY / CATCH

Modern exception handling uses TRY and CATCH blocks. The idea: run code inside TRY. If an exception is raised, control jumps to CATCH.

TRY.
    DATA(lv_result) = 10 / iv_divisor.
    WRITE: / 'Result:', lv_result.

  CATCH cx_sy_zerodivide INTO DATA(lo_exc).
    WRITE: / 'Cannot divide by zero!'.
    WRITE: / lo_exc->get_text( ).

  CATCH cx_root INTO DATA(lo_root).
    WRITE: / 'Unexpected error:', lo_root->get_text( ).

ENDTRY.

Raising exceptions

When writing your own classes, you can raise exceptions intentionally to signal problems:

CLASS zcl_validator DEFINITION.
  PUBLIC SECTION.
    METHODS validate
      IMPORTING iv_amount TYPE p
      RAISING   cx_sy_arithmetic_error.
ENDCLASS.

CLASS zcl_validator IMPLEMENTATION.
  METHOD validate.
    IF iv_amount < 0.
      RAISE EXCEPTION TYPE cx_sy_arithmetic_error.
    ENDIF.
  ENDMETHOD.
ENDCLASS.

Classic exceptions — EXCEPTIONS parameter

Older function modules use the EXCEPTIONS parameter. You list possible exceptions and check sy-subrc after the call:

CALL FUNCTION 'Z_VALIDATE_DATE'
  EXPORTING
    iv_date = sy-datum
  EXCEPTIONS
    invalid_date = 1
    others       = 2.

IF sy-subrc = 1.
  WRITE: / 'Date is invalid.'.
ENDIF.

⚙️ Debugging a Background Job

Background jobs run without a user session, so you cannot just type /h. But you can still debug them. Three approaches:

Approach 1 — Debug background job from SM37

1. Go to transaction SM37 (Job Overview)
2. Find and select the job
3. Click Job → Debug (or the Debug button)
4. A dialog appears asking for a user. Enter your username
5. Release the job. When it starts, your debugger opens

Approach 2 — WAIT UP TO statement

WAIT UP TO 10 SECONDS.  " Creates a debugging window

Approach 3 — Remote debugging

For RFC and HTTP calls, configure remote debugging in the target system so calls from a specific user trigger the debugger automatically.

📊 ST05 and SAT — Performance Tools (Intro)

Debugging is not only about bugs. It is also about performance. Two tools you must know:

📝 Chapter Summary

• The ABAP Debugger pauses execution so you can inspect variables and program flow.
• Activate it with /h in the command field, or set a breakpoint in the editor.
• F6 = Step Over (next line). F8 = Execute to next breakpoint.
• Breakpoints pause at a specific line. Watchpoints pause when a variable changes value.
• A short dump is a runtime error. Read it in ST22 to find the cause.
• Six MESSAGE types: A (Abend), E (Error), W (Warning), I (Info), S (Success), X (Exit).
• Class-based exceptions use TRY / CATCH. Use them for all new code.
• Debug background jobs via SM37 → Job → Debug.
• ST05 traces database calls. SAT measures code execution time.