fail-early-pattern
정보
이 스킬은 개발자들에게 가드 클로즈와 어설션을 사용하여 입력값을 검증하고 즉시 오류를 보고하는 '빠른 실패' 패턴을 구현하는 방법을 가르칩니다. R 중심 예제와 다중 언어 가이드를 통해 견고한 함수 작성, API 보강, 오류 발생 가능성이 있는 코드 리팩토링 방법을 제공합니다. 외부 입력을 수락할 때, CRAN 제출을 준비할 때, 또는 암묵적 실패를 방지하기 위해 코드를 검토할 때 활용하세요.
빠른 설치
Claude Code
추천npx skills add pjt222/agent-almanac -a claude-code/plugin add https://github.com/pjt222/agent-almanacgit clone https://github.com/pjt222/agent-almanac.git ~/.claude/skills/fail-early-patternClaude Code에서 이 명령을 복사하여 붙여넣어 스킬을 설치하세요
문서
Fail Early
If fails → fail early, loud, w/ context. Codifies: validate inputs at boundaries, guard clauses reject bad state before propagates, err msgs answer what failed, where, why, how to fix.
Use When
- Writing/reviewing fns accepting external input (user data, API, file)
- Input validation before CRAN submission
- Refactor silent wrong results → errors
- Review PRs for err-handling quality
- Harden internal APIs vs invalid args
In
- Required: Fn/module to apply pattern
- Required: Trust boundaries (where external data enters)
- Optional: Existing err-handling to refactor
- Optional: Target language (default R; also Python, TypeScript, Rust)
Do
Step 1: Trust Boundaries
Map external data entry. Points needing validation:
- Public API fns (exported package)
- User-facing params
- File I/O (configs, data, uploads)
- Net responses (APIs, DBs)
- Env vars + system config
Internal helpers called only by validated code generally no redundant validation.
→ List entry points where untrusted data crosses.
If err: unclear → trace backwards from err logs/bug reports → find where bad data entered.
Step 2: Guard Clauses at Entry
Validate at top of each public fn before work.
R (base):
calculate_summary <- function(data, method = c("mean", "median", "trim"), trim_pct = 0.1) {
# Guard: type check
if (!is.data.frame(data)) {
stop("'data' must be a data frame, not ", class(data)[[1]], call. = FALSE)
}
# Guard: non-empty
if (nrow(data) == 0L) {
stop("'data' must have at least one row", call. = FALSE)
}
# Guard: argument matching
method <- match.arg(method)
# Guard: range check
if (!is.numeric(trim_pct) || trim_pct < 0 || trim_pct > 0.5) {
stop("'trim_pct' must be a number between 0 and 0.5, got: ", trim_pct, call. = FALSE)
}
# --- All guards passed, begin real work ---
# ...
}
R (rlang/cli — preferred for packages):
calculate_summary <- function(data, method = c("mean", "median", "trim"), trim_pct = 0.1) {
rlang::check_required(data)
if (!is.data.frame(data)) {
cli::cli_abort("{.arg data} must be a data frame, not {.cls {class(data)}}.")
}
if (nrow(data) == 0L) {
cli::cli_abort("{.arg data} must have at least one row.")
}
method <- rlang::arg_match(method)
if (!is.numeric(trim_pct) || trim_pct < 0 || trim_pct > 0.5) {
cli::cli_abort("{.arg trim_pct} must be between 0 and 0.5, not {.val {trim_pct}}.")
}
# ...
}
General (TypeScript):
function calculateSummary(data: DataFrame, method: Method, trimPct: number): Summary {
if (data.rows.length === 0) {
throw new Error(`data must have at least one row`);
}
if (trimPct < 0 || trimPct > 0.5) {
throw new RangeError(`trimPct must be between 0 and 0.5, got: ${trimPct}`);
}
// ...
}
→ Every public fn opens w/ guards rejecting invalid before side effects/computation.
If err: validation long (>15 lines of guards) → extract validate_* helper or stopifnot() for simple type assertions.
Step 3: Meaningful Err Msgs
Every msg answers 4:
- What failed — param/op
- Where — fn name/context (auto w/
cli::cli_abort) - Why — expected vs received
- How to fix — when fix non-obvious
Good:
# What + Why (expected vs. actual)
stop("'n' must be a positive integer, got: ", n, call. = FALSE)
# What + Why + How to fix
cli::cli_abort(c(
"{.arg config_path} does not exist: {.file {config_path}}",
"i" = "Create it with {.run create_config({.file {config_path}})}."
))
# What + context
cli::cli_abort(c(
"Column {.val {col_name}} not found in {.arg data}.",
"i" = "Available columns: {.val {names(data)}}"
))
Bad:
stop("Error") # What failed? No idea
stop("Invalid input") # Which input? What's wrong with it?
stop(paste("Error in step", i)) # No actionable information
→ Msgs self-documenting — dev seeing first time diagnose + fix w/o reading source.
If err: review 3 most recent bug reports. Required reading source to understand → msgs need improvement.
Step 4: Prefer stop() vs warning()
stop() (or cli::cli_abort()) when can't produce correct result. warning() only when still meaningful but caller should know.
Rule: User could silently get wrong answer → stop() not warning().
# CORRECT: stop when result would be wrong
read_config <- function(path) {
if (!file.exists(path)) {
stop("Config file not found: ", path, call. = FALSE)
}
yaml::read_yaml(path)
}
# CORRECT: warn when result is still usable
summarize_data <- function(data) {
if (any(is.na(data$value))) {
warning(sum(is.na(data$value)), " NA values dropped from 'value' column", call. = FALSE)
data <- data[!is.na(data$value), ]
}
# proceed with valid data
}
→ stop() for incorrect results; warning() for degraded-but-valid.
If err: audit existing warning() calls. Returns nonsense after → change to stop().
Step 5: Assertions for Internal Invariants
"Should never happen" → assertions. Catches programmer errs during dev:
# R: stopifnot for internal invariants
process_chunk <- function(chunk, total_size) {
stopifnot(
is.list(chunk),
length(chunk) > 0,
total_size > 0
)
# ...
}
# R: explicit assertion with context
merge_results <- function(left, right) {
if (ncol(left) != ncol(right)) {
stop("Internal error: column count mismatch (", ncol(left), " vs ", ncol(right),
"). This is a bug — please report it.", call. = FALSE)
}
# ...
}
→ Invariants asserted → bugs surface immediately at violation site, not 3 calls later cryptic.
If err: stopifnot() msgs too cryptic → switch explicit if/stop w/ context.
Step 6: Refactor Anti-Patterns
Common anti-patterns:
Anti-pattern 1: Empty tryCatch (swallowing)
# BEFORE: Error silently disappears
result <- tryCatch(
parse_data(input),
error = function(e) NULL
)
# AFTER: Log, re-throw, or return a typed error
result <- tryCatch(
parse_data(input),
error = function(e) {
cli::cli_abort("Failed to parse input: {e$message}", parent = e)
}
)
Anti-pattern 2: Defaults masking bad input
# BEFORE: Caller never knows their input was ignored
process <- function(x = 10) {
if (!is.numeric(x)) x <- 10 # silently replaces bad input
x * 2
}
# AFTER: Tell the caller about the problem
process <- function(x = 10) {
if (!is.numeric(x)) {
stop("'x' must be numeric, got ", class(x)[[1]], call. = FALSE)
}
x * 2
}
Anti-pattern 3: suppressWarnings as fix
# BEFORE: Hiding the symptom instead of fixing the cause
result <- suppressWarnings(as.numeric(user_input))
# AFTER: Validate explicitly, handle the expected case
if (!grepl("^-?\\d+\\.?\\d*$", user_input)) {
stop("Expected a number, got: '", user_input, "'", call. = FALSE)
}
result <- as.numeric(user_input)
Anti-pattern 4: Catch-all handlers
# BEFORE: Every error treated the same
tryCatch(
complex_operation(),
error = function(e) message("Something went wrong")
)
# AFTER: Handle specific conditions, let unexpected ones propagate
tryCatch(
complex_operation(),
custom_validation_error = function(e) {
cli::cli_warn("Validation issue: {e$message}")
fallback_value
}
# Unexpected errors propagate naturally
)
→ Anti-patterns replaced w/ explicit validation or specific err handling.
If err: remove tryCatch causes cascading → upstream has validation gap. Fix source not symptom.
Step 7: Validate Refactoring
Run tests to confirm err paths work:
# Verify error messages are triggered
testthat::expect_error(calculate_summary("not_a_df"), "must be a data frame")
testthat::expect_error(calculate_summary(data.frame()), "at least one row")
testthat::expect_error(calculate_summary(mtcars, trim_pct = 2), "between 0 and 0.5")
# Verify valid inputs still work
testthat::expect_no_error(calculate_summary(mtcars, method = "mean"))
# Run full test suite
Rscript -e "devtools::test()"
→ All tests pass. Err-path tests confirm bad input triggers expected msg.
If err: existing tests relied on silent failures (returning NULL on bad input) → update to expect new err.
Check
- Every public fn validates inputs before work
- Err msgs: what, where, why, how to fix
-
stop()for incorrect results -
warning()only degraded-but-valid - No empty
tryCatchswallowing - No
suppressWarnings()as validation substitute - No defaults silently masking invalid
- Invariants use
stopifnot()or explicit assertions - Err-path tests per guard
- Test suite passes post-refactor
Traps
- Validate too deep: Validate at boundaries (public API), not every internal helper. Over-validation adds noise + hurts perf.
- Msgs no context:
"Invalid input"forces caller guess. Always param name, expected type/range, actual value. - warning() when mean stop(): Returns garbage after warn → wrong silently. Use
stop(), let caller decide. - Swallow in tryCatch:
tryCatch(..., error = function(e) NULL)hides bugs. Must catch → log or re-throw w/ context. - Forget call. = FALSE: R
stop("msg")includes call by default — noisy end users. Usecall. = FALSEuser-facing.cli::cli_abort()does auto. - Validate in tests not code: Tests verify behavior not protect production. Validation in fn itself.
- Wrong R binary hybrid systems: WSL/Docker,
Rscriptmay resolve cross-platform wrapper not native R. Checkwhich Rscript && Rscript --version. Prefer native (/usr/local/bin/RscriptLinux/WSL). See Setting Up Your Environment.
→
write-testthat-tests— tests verifying err pathsreview-pull-request— review for missing validation + silent failuresreview-software-architecture— err-handling strategy system levelcreate-skill— new skills following agentskills.iosecurity-audit-codebase— security-focused review overlapping validation
GitHub 저장소
연관 스킬
evaluating-llms-harness
테스팅이 Claude Skill은 MMLU, GSM8K를 포함한 60개 이상의 표준화된 학술 과제에서 LLM 성능을 벤치마크하기 위해 lm-evaluation-harness를 실행합니다. 개발자들이 모델 품질을 비교하고, 학습 진행 상황을 추적하거나 학술 결과를 보고할 수 있도록 설계되었습니다. 이 도구는 HuggingFace와 vLLM 모델을 포함한 다양한 백엔드를 지원합니다.
cloudflare-cron-triggers
테스팅이 스킬은 cron 표현식을 사용하여 Worker를 스케줄링하기 위한 Cloudflare Cron Triggers 구현에 관한 포괄적인 지식을 제공합니다. 주기적 작업, 유지보수 작업, 자동화된 워크플로우 설정 방법을 다루며, 잘못된 cron 표현식이나 시간대 문제 같은 일반적인 이슈들을 해결하는 방법을 포함합니다. 개발자들은 이를 통해 스케줄된 핸들러 구성, cron 트리거 테스트, Workflows 및 Green Compute와의 연동 작업을 수행할 수 있습니다.
webapp-testing
테스팅이 Claude Skill은 Python 스크립트를 통해 로컬 웹 애플리케이션을 테스트하기 위한 Playwright 기반 툴킷을 제공합니다. 프론트엔드 검증, UI 디버깅, 스크린샷 캡처, 로그 확인 기능을 지원하며 서버 라이프사이클을 관리합니다. 브라우저 자동화 작업에 사용하되 컨텍스트 오염을 방지하기 위해 소스 코드를 읽지 않고 스크립트를 직접 실행하세요.
finishing-a-development-branch
테스팅이 스킬은 테스트 통과를 확인한 후 체계적인 통합 옵션을 제시하여 개발자가 완성된 작업을 마무리하도록 돕습니다. 구현이 완료된 후 머지, PR 생성, 브랜치 정리와 같은 워크플로우를 안내합니다. 코드가 준비되고 테스트가 완료되었을 때 개발 프로세스를 체계적으로 마무리하기 위해 사용하세요.
