외부 인터페이스에 오류 처리를 넣었는데 상태 코드만 보게 했더니 아무것도 안 잡혔다. 그런데 데이터도 들어오지 않았다.
Table of contents
Open Table of contents
오류가 본문에 담겨 온다
응답을 찍어 보니 상태 코드는 정상이고 본문에 오류 코드와 메시지가 들어 있었다. 오래된 인터페이스일수록 이런 형태가 드물지 않다.
상태 코드를 전송 계층 결과로만 쓰고 응용 계층 결과는 본문에 담는 설계다. 그러면 상태 코드만 보는 검사는 구조적으로 아무것도 못 잡는다.
전송 계층과 응용 계층
검사를 두 층으로 나눠서 상태 코드가 정상이 아니면 전송 오류로 던지고 본문의 결과 코드가 정상이 아니면 응용 오류로 던지게 했다. 두 오류를 다른 예외로 만든 것은 대응이 다르기 때문이다.
전송 오류는 재시도할 만하지만 응용 오류는 대개 재시도해도 같은 결과가 온다. 한 종류로 뭉뚱그리면 재시도 정책을 갈라 붙일 수 없다.
문서의 숫자와 계정별 값
오류 코드 중 하나가 호출 한도 초과였는데 문서에 적힌 숫자와 우리 계정의 실제 한도가 달랐다. 문서의 값은 기본값 안내였고 실제 한도는 계정별로 정해지고 있었다.
처음에는 코드에 한도를 상수로 넣고 직접 세려 했다. 틀린 값을 넣으면 아직 여유가 있는데 스스로 멈추므로 안 넣은 것보다 나쁘다.
세지 않고 반응하는 방식
잔여 한도를 조회하는 경로가 없어서 우리가 세는 방식 자체가 성립하지 않았다. 그래서 한도 초과 코드를 받으면 그날 안 보내고 물러나는 방식으로 바꿨다.
우리가 세지 않고 상대가 알려 줄 때 반응하므로 한도가 바뀌어도 코드를 고칠 필요가 없다. 값이 바깥에서 정해지는 것은 바깥이 알려 줄 때까지 기다리는 편이 맞았다.
눈으로 같아 보이는 다른 문자
응답 값을 거르는 코드에서 분명 맞는 값인데 안 걸리는 일이 있었다. 바이트로 찍어 보니 내가 쓴 가운뎃점과 응답에 온 문자가 서로 다른 코드였고 값 뒤에 공백 패딩도 붙어 있었다.
문자열 비교가 안 되면 눈으로 보지 말고 바이트로 찍어 봐야 갈린다. 한도 부분도 처음에는 명령줄로 몇 번 호출해 보고 제공하지 않는다고 결론냈는데 개발 가이드와 이용약관을 1차 소스로 읽으니 거기 있었으므로 도구로 두드려 본 것으로 없다고 결론 내면 안 됐다.
정리
- 상태 코드가 정상이어도 본문에 오류가 담겨 올 수 있다
- 상태 코드만 보는 검사는 구조적으로 그것을 못 잡는다
- 검사를 전송 계층과 응용 계층 둘로 나눈다
- 두 오류는 재시도 정책이 다르므로 예외도 나눈다
- 한도가 계정마다 다르고 문서의 숫자는 기본값 안내일 수 있다
- 틀린 상수는 안 넣은 것보다 나쁘다
- 우리가 세지 말고 상대가 알려 줄 때 물러난다
- 도구로 몇 번 두드려 본 것으로 없다고 결론 내지 않는다