오류, 경고, 진단

리더, 정규화, 런타임, 경고, 자원 결과는 서로 다른 단계와 결정적 채널을 가집니다.

언제 필요한가요?

코드를 바꾸기 전에 진단 단계를 먼저 읽으세요. 리더 오류는 철자 수정을, 정규화 오류는 폼 형태 수정을, 런타임 오류는 유효한 폼이 실행 중 실패한 원인 확인을 요구합니다.

실행으로 확인하기

LISPEX
(guard (e (else (error-object-message e))) (car 1))

관측 결과

OUTPUT
"car: expected a pair, got 1"

예제 읽기

car가 쌍 대신 1을 받아 잡을 수 있는 런타임 오류를 냅니다. guard가 오류 객체를 잡고 안정된 메시지를 반환합니다. 따라서 호스트 스택 추적을 내지 않고 문자열 값으로 정상 종료합니다.

이 순서로 생각하세요

  • 런타임 오류는 E3xx 코드, 안정된 템플릿, 결정적 irritant 표기, 감싸는 호출 위치를 사용합니다.
  • 경고는 순서 있는 관측입니다. 실제 % 호출은 modulo를 실행하기 전에 W330을 내고, 실제 list-first·list-rest 호출은 car·cdr를 실행하기 전에 W331을 냅니다. 소스 호출 위치마다 한 번만 경고하며, 같은 이름을 가린 바인딩은 경고하지 않고, 뒤의 연산이 실패해도 경고는 남습니다.
  • 첫 미처리 오류는 호스트 스택 추적 없이 중단하며 자원 고갈은 잡을 수 있는 E3xx 밖에 있습니다.

빠르게 고르기

분류나타나는 때먼저 할 일
E1xx 리더소스가 datum이 될 수 없음강조된 토큰이나 구분자 수정
E2xx 정규화폼의 정적 형태가 잘못됨폼 철자·위치·인자 수 확인
E3xx 런타임평가가 잘못된 연산에 도달이름 붙은 프로시저와 문제 값을 확인
W3xx 경고폐기 예정 표면을 쓰지만 실행은 계속됨알려 준 대체 항목으로 이동
자원 결과프로필 한도에 도달작업을 줄이거나 맞는 선언 프로필 선택

흔한 오해

경고는 stdout이 아니며 재정렬하거나 진단에 합치면 안 됩니다.

새 코드에는 modulo, first, rest를 쓰세요. 폐기 예정 표기는 호환을 위해서만 계속 실행됩니다.

현재 경계

  • 플랫폼 panic, 빈 크래시, 비결정적 호스트 텍스트는 유효한 게스트 진단이 아닙니다.

다음으로

정확한 코드 조회는 진단 카탈로그에서, 결정을 내기 전 검증 흐름은 오류 가이드에서 이어집니다.

진단 카탈로그 · 오류 가이드