---
id: c-debugging
title: "C Debugging"
category: "Programming_Language"
status: "draft"
verification_status: "conceptual"
canonical_id: ""
aliases: ["print debugging", "breakpoints", "debugging vs error handling", "C 디버깅"]
duplicate_of: ""
source_trust_level: "B"
confidence_score: 0.85
created_at: 2026-07-04
updated_at: 2026-07-04
review_reason: ""
merge_history: []
tags: ["c", "programming-language", "w3schools", "debugging"]
raw_sources: ["https://www.w3schools.com/c/c_debugging.php"]
applied_in: []
github_commit: ""
---

# [[C Debugging]]

## 🎯 한 줄 통찰 (One-line insight)
The chapter's closing distinction reframes debugging and error handling as two DIFFERENT PHASES of the same concern, not competing techniques: debugging is about finding/fixing mistakes DURING DEVELOPMENT, while error handling is about gracefully responding to problems WHILE THE PROGRAM RUNS in production — meaning a well-built C program needs both, applied at different times, not one instead of the other. [S1]

## 🧠 핵심 개념 (Core concepts)
- **Print debugging** — sprinkling `printf()` calls to trace how far execution gets before something goes wrong; if an expected message never prints, the crash happened before that line. [S1]
- **Checking variable values** — printing intermediate results to catch LOGIC errors (e.g. expecting 15 but getting 5 reveals a wrong operator, not a crash). [S1]
- **IDE debuggers** — breakpoints, line-by-line stepping, and variable-watching, available in IDEs like Visual Studio/Code::Blocks/VS Code; recommended as a step UP from `printf()` debugging once comfortable with the basics. [S1]
- **Reading error messages literally** — the compiler/runtime often states exactly what's wrong and where (e.g. `expected ';' before 'printf'` → the fix is adding the missing semicolon). [S1]
- **Defensive checks preventing crashes** — proactively checking conditions that are KNOWN to cause crashes (e.g. `if (y != 0)` before dividing, `if (index >= 0 && index < 3)` before array access) converts a crash into a graceful error message. [S1]

## 📖 세부 내용 (Details)
- Print debugging locating a crash point: `printf("Before division\n"); int z = x / y; printf("After division\n");` — if "After division" never prints, the crash happened at the division. [S1]
- Logic-error detection via variable printing: `int result = x - y; printf("Result: %d\n", result); // Result: 5 (expected 15 — wrong operator used)`. [S1]
- Preventing a divide-by-zero crash with a defensive check: `if (y != 0) { int z = x / y; printf("Result: %d\n", z); } else { printf("Error: Division by zero!\n"); }`. [S1]
- Preventing an out-of-bounds crash with a defensive check: `if (index >= 0 && index < 3) { printf("Value = %d\n", numbers[index]); } else { printf("Error: Index out of bounds!\n"); }`. [S1]

## ⚖️ 모순 및 업데이트 (Contradictions & updates)
- **디버깅과 에러 처리는 서로 다른 단계**: 디버깅은 개발 중 버그를 찾고 고치는 활동이고, 에러 처리는 프로그램이 실제로 실행되는 중 문제에 대응하는 것이라는 점이 명확히 구분되며, 둘 다 필요하다는 점이 결론으로 제시됨. [S1]

## 🛠️ 적용 사례 (Applied in summary)
0으로 나누기와 배열 범위 초과 접근이라는 두 가지 대표적 크래시 상황을 사전 조건 검사로 방지하는 방법이 원문에서 직접 실전 활용 사례로 제시됨. [S1]

## 💻 코드 패턴 (Code patterns)
Preventing a division-by-zero crash with a defensive check instead of a printf-based fix (C):
```c
int x = 10;
int y = 0;
if (y != 0) {
  int z = x / y;
  printf("Result: %d\n", z);
} else {
  printf("Error: Division by zero!\n");
}
```

## ✅ 검증 상태 및 신뢰도
- **상태:** draft
- **검증 단계:** conceptual
- **출처 신뢰도:** B (W3Schools — widely used educational reference, not a primary standards body)
- **신뢰 점수:** 0.85
- **중복 검사 결과:** 신규 생성 (New discovery)

## 🔗 지식 그래프 (Knowledge Graph)
- **상위/루트:** [[C Tutorial]]
- **관련 개념:** [[C Input Validation]], [[C Errors]], [[C Files]]
- **참조 맥락:** 에러 및 디버깅 섹션 마지막 — 파일 입출력(Files) 섹션으로 이어짐.

## 📚 출처 (Sources)
- [S1] W3Schools — C Debugging — https://www.w3schools.com/c/c_debugging.php

## 📝 변경 이력 (Change history)
- 2026-07-04: Initial draft synthesized from the W3Schools "C Debugging" page (Astra wiki-curation, P-Reinforce v3.1 format).
