Abseil Code Review · 14/79

absl::Status — exception-free error handling

2026년 6월 9일 · Hawk · 4분 읽기

cpp abseil status error-handling no-exception

한 줄 요약: absl::Status는 Google의 사내 표준 에러 타입이다. exception 없이 에러를 값으로 전달하고, 17개의 canonical code로 종류를 분류하며, ok 경로에서는 포인터 한 개의 크기만 차지하도록 설계되었다.

#어떤 문제를 푸는가

Google의 C++ 코드베이스는 exception을 거의 쓰지 않는다. 이유는 여러 가지가 있다.

성능 예측 가능성 — exception은 throw 비용이 비대칭적으로 크다.
ABI 호환 — -fno-exceptions 빌드가 일부 환경에서 필수.
history — sub-second latency를 요구하는 시스템에서 exception이 부담.
명시성 — 함수 시그니처에서 에러 가능성이 드러남.

대안이 필요했다. int errno 같은 C 스타일은 type-safe가 부족하고 메시지를 담을 수 없다. std::error_code는 가볍지만 디버깅에 필요한 컨텍스트가 없다. absl::Status는 그 사이를 메운다.

#기본 사용

1
#include "absl/status/status.h"
2

3
absl::Status ValidateInput(const Request& req) {
4
    if (req.name().empty()) {
5
        return absl::InvalidArgumentError("name must not be empty");
6
    }
7
    if (req.age() < 0) {
8
        return absl::OutOfRangeError(
9
            absl::StrCat("age must be non-negative, got ", req.age()));
10
    }
11
    return absl::OkStatus();
12
}
13

14
void Handle(const Request& req) {
15
    absl::Status s = ValidateInput(req);
16
    if (!s.ok()) {
17
        LOG(ERROR) << s;
18
        return;
19
    }
20
    // ok path
21
    Process(req);
22
}

핵심 패턴.

성공은 OkStatus().
실패는 XxxError(msg) 형태의 factory.
호출자는 s.ok()로 검사 또는 매크로(다음 편)로 자동 전파.

#17개의 Canonical Code

17개 코드를 색으로 분류해 보면 다음과 같다.

Status canonical codes

1
namespace absl {
2
enum class StatusCode : int {
3
    kOk = 0,
4
    kCancelled = 1,
5
    kUnknown = 2,
6
    kInvalidArgument = 3,
7
    kDeadlineExceeded = 4,
8
    kNotFound = 5,
9
    kAlreadyExists = 6,
10
    kPermissionDenied = 7,
11
    kResourceExhausted = 8,
12
    kFailedPrecondition = 9,
13
    kAborted = 10,
14
    kOutOfRange = 11,
15
    kUnimplemented = 12,
16
    kInternal = 13,
17
    kUnavailable = 14,
18
    kDataLoss = 15,
19
    kUnauthenticated = 16,
20
};
21
}  // namespace absl

이 코드는 gRPC의 error code와 1

일치한다. 같은 분류 체계.

#각 코드의 의미

코드	언제
`OK`	성공
`Cancelled`	호출자가 취소 (CTRL+C, deadline)
`Unknown`	분류 불가 (다른 시스템에서 변환 시 fallback)
`InvalidArgument`	입력이 형식상 잘못 (검증 실패)
`DeadlineExceeded`	시간 초과
`NotFound`	요청한 리소스가 없음
`AlreadyExists`	만들려는 리소스가 이미 있음
`PermissionDenied`	권한 부족 (인증은 OK, 권한이 부족)
`ResourceExhausted`	quota, rate limit 등
`FailedPrecondition`	시스템 상태가 잘못 (전제 위반)
`Aborted`	동시성 충돌, 트랜잭션 abort
`OutOfRange`	값이 범위 밖 (validation의 하위)
`Unimplemented`	기능 미구현
`Internal`	내부 invariant 위반 (보통 버그)
`Unavailable`	일시적 장애, retry 가능
`DataLoss`	데이터 손상/유실
`Unauthenticated`	인증 실패

코드 선택은 의외로 미묘하다. FailedPrecondition vs InvalidArgument vs OutOfRange의 차이가 자주 헷갈린다. gRPC 문서가 가이드라인을 제공한다.

#API 메서드

1
absl::Status s = SomeOp();
2

3
// 검사
4
bool ok = s.ok();
5
absl::StatusCode code = s.code();
6
absl::string_view msg = s.message();
7

8
// 출력 — 디버깅용
9
LOG(INFO) << s;  // "INVALID_ARGUMENT: name must not be empty"
10
std::string str = s.ToString();
11

12
// 비교
13
if (s.code() == absl::StatusCode::kNotFound) { /*...*/ }

#내부 구현 — 8바이트만으로

1
// absl/status/status.h 의사 코드
2
class Status {
3
public:
4
    // ...
5
private:
6
    uintptr_t rep_;
7
    // 하위 비트로 ok/error 구분
8
    // ok이면 특수 값 (0 또는 특정 마커)
9
    // error이면 heap-allocated payload를 가리키는 포인터
10
};
11

12
static_assert(sizeof(Status) == sizeof(void*));

가장 중요한 최적화. ok status는 heap 할당 없이 stack에 그대로. 8바이트.

1
inline Status OkStatus() {
2
    return Status();  // rep_ = 0 (또는 ok marker)
3
}
4

5
inline bool Status::ok() const {
6
    return rep_ == kOkRep;  // 단순 비교
7
}

성공 경로가 hot path인 대부분의 코드에서, Status는 사실상 비용이 없다. error 경로에서만 heap 할당이 일어난다.

#error 경로

error status를 만들면 다음이 일어난다.

1
absl::Status MakeError(StatusCode code, absl::string_view msg) {
2
    // 1. heap allocation
3
    auto* rep = new StatusRep{
4
        code,
5
        std::string(msg),
6
        // payload map (보통 비어 있음)
7
    };
8
    // 2. rep_에 포인터 저장 (low bit로 error 표시)
9
    return Status(reinterpret_cast<uintptr_t>(rep) | 1);
10
}

StatusRep는 reference-counted. status를 복사해도 같은 payload를 가리킨다.

#Factory 함수

각 canonical code에 대응하는 factory가 있다.

1
absl::Status absl::OkStatus();
2
absl::Status absl::CancelledError(absl::string_view msg);
3
absl::Status absl::UnknownError(absl::string_view msg);
4
absl::Status absl::InvalidArgumentError(absl::string_view msg);
5
absl::Status absl::DeadlineExceededError(absl::string_view msg);
6
absl::Status absl::NotFoundError(absl::string_view msg);
7
absl::Status absl::AlreadyExistsError(absl::string_view msg);
8
absl::Status absl::PermissionDeniedError(absl::string_view msg);
9
absl::Status absl::ResourceExhaustedError(absl::string_view msg);
10
absl::Status absl::FailedPreconditionError(absl::string_view msg);
11
absl::Status absl::AbortedError(absl::string_view msg);
12
absl::Status absl::OutOfRangeError(absl::string_view msg);
13
absl::Status absl::UnimplementedError(absl::string_view msg);
14
absl::Status absl::InternalError(absl::string_view msg);
15
absl::Status absl::UnavailableError(absl::string_view msg);
16
absl::Status absl::DataLossError(absl::string_view msg);
17
absl::Status absl::UnauthenticatedError(absl::string_view msg);

대응되는 predicate도 있다.

1
bool absl::IsCancelled(const Status&);
2
bool absl::IsInvalidArgument(const Status&);
3
bool absl::IsNotFound(const Status&);
4
// ... 모든 코드에 대해

#코드 리뷰 포인트

#적절한 code 선택

1
// 회피 — 모든 에러를 Internal로
2
return absl::InternalError("something failed");
3

4
// Good — 의미 있는 분류
5
if (input.empty()) return absl::InvalidArgumentError("input is empty");
6
if (!exists) return absl::NotFoundError(absl::StrCat("not found: ", key));
7
if (!has_permission) return absl::PermissionDeniedError("admin only");

Internal은 “이건 진짜 내부 버그”일 때만. 외부 입력으로 인한 에러는 InvalidArgument / OutOfRange / FailedPrecondition.

#메시지에 충분한 컨텍스트

1
// 회피 — 정보 부족
2
return absl::NotFoundError("not found");
3

4
// Good — 무엇이 어디서 누락됐는지
5
return absl::NotFoundError(
6
    absl::StrCat("user not found: id=", user_id, " in table=", table));

#Status를 무시하지 말 것

1
// 회피
2
SomeOp();  // Status 반환값을 버림 — 경고도 안 남
3

4
// Good
5
absl::Status s = SomeOp();
6
if (!s.ok()) {
7
    LOG(ERROR) << s;
8
    return s;
9
}

absl::Status는 [[nodiscard]]이므로 컴파일러가 무시를 경고한다. 그래도 명시적 처리가 권장.

#자주 보는 안티패턴

1
// 회피 — bool 반환 + 별도 에러 메시지
2
bool DoIt(std::string* err_msg);
3
if (!DoIt(&msg)) {
4
    LOG(ERROR) << msg;
5
}
6
// Status가 둘을 한 번에 표현.
7

8
// Good
9
absl::Status DoIt();
10
if (auto s = DoIt(); !s.ok()) LOG(ERROR) << s;

1
// 회피 — exception을 catch 후 Status로 변환을 매번
2
try {
3
    DoExternal();
4
} catch (const std::exception& e) {
5
    return absl::InternalError(e.what());
6
}
7
// catch는 Abseil 코드의 끝(public API boundary)에서만.
8

9
// Good — 가능하면 exception 안 던지는 라이브러리 선택
10
// 어쩔 수 없으면 wrapper에서 한 번만 변환

1
// 회피 — Status를 const Status&가 아닌 값으로 받아 modify
2
absl::Status TryIt() {
3
    absl::Status s = SomeOp();
4
    s = absl::OkStatus();  // 원본 무시
5
    return s;
6
}
7

8
// Good
9
absl::Status TryIt() {
10
    if (auto s = SomeOp(); !s.ok()) {
11
        // 처리
12
    }
13
    return absl::OkStatus();
14
}

#std와의 비교

도구	장점	단점
`std::error_code`	가벼움 (16바이트), 표준	메시지 없음, error category 등록 복잡
C++ exception	컴파일러 통합	runtime 비용, ABI 영향
`bool` + out param	단순	메시지·코드 분리
`absl::Status`	메시지·코드·payload 통합, OK 경로 zero-overhead	Abseil 의존