스위프트의 오류 처리 모델은 C++ 예외의 보이지 않는 제어 흐름 점프와 자바 체크된 예외의 관료적 경직성에 대한 직접적인 응답으로 등장했습니다. 전통적인 예외 처리의 근본적인 문제는 throw 문이 중간 호출 지점에서 구문적 마커 없이 여러 스택 프레임 간에 제어를 전송할 수 있어 코드 검토 및 정적 분석이 신뢰할 수 없게 만든다는 것입니다. 스위프트는 오류를 태그된 합집합 표현을 사용한 일급 반환 값으로 처리하여, try 키워드가 소스 텍스트에서 잠재적 종료 지점을 명시하는 컴파일러 요구 사항 주석 역할을 합니다.
이 구조적 선택은 지역적 추론을 강제합니다: try를 포함하는 코드의 모든 줄은 실행이 다음 문장으로 계속되지 않을 수 있음을 독자에게 즉시 신호합니다. Objective-C의 @try/@catch 블록은 오류가 발생하지 않더라도 런타임 오버헤드를 유발하는 반면, 스위프트의 접근 방식은 실제 오류가 발생하지 않는 한 오류 전파를 최적화한 제로 비용 추상화를 사용합니다. 따라서 try 키워드는 시각적 안전 마커이자 타입 시스템을 통해 철저한 오류 처리를 보장하는 컴파일러 지시어로 작용합니다.
의료 기록 파이프라인을 설계하는 동안, 우리 팀은 세 가지 오류 발생 가능성이 있는 작업을 순서대로 진행해야 했습니다: JSON 메타데이터 파싱, X.509 디지털 서명 검증, 및 AES-256을 사용한 환자 데이터 복호화. 각 단계는 구문이 잘못된 경우, 만료된 인증서, 또는 잘못된 키와 같은 고유한 오류 범주를 생성했고, 우리는 HIPAA 감사 로그를 위해 어떤 단계에서 실패했는지에 대한 세부 정보를 요구했습니다.
우리의 초기 접근 방식은 guard let 문이 있는 Optional 반환 유형을 사용했으며, parseMetadata() -> Metadata?는 실패 시 nil을 반환했습니다. 이는 디버깅에 재앙적이었고, 프로덕션 로그는 단순히 복호화가 실패했음을 보여주었을 뿐, 입력이 손상되었는지 또는 서명 불일치로 인해 실패했는지를 알 수 없었습니다. 중첩된 guard 문으로 인해 생성된 절벽 구조는 선형 데이터 흐름을 가리고 리팩토링을 오류를 발생시키기 쉽게 만들었습니다.
그 후 우리는 명시적인 Result<Metadata, ParseError> 반환으로 실험했습니다. 이 방식은 오류 컨텍스트를 보존했지만, 보일러플레이트가 압도적으로 많아졌습니다. 작업을 구성하려면 장황한 switch 문이나 flatMap 체인이 필요하여 코드를 Objective-C 오류 포인터 패턴보다 유지 관리하기 힘들어졌습니다. 파이프라인을 통해 결과를 수동으로 연결하는 인지적 부담이 안전 이점보다 훨씬 컸습니다.
결국 우리는 Error 프로토콜을 준수하는 사용자 정의 MedicalRecordError 열거형을 사용하는 던지기 함수로 전환했습니다. 각 단계를 throws로 표시함으로써, 우리는 try 키워드를 활용하여 보안 감사 중에 실패 지점을 가시화하고 오류가 중앙 집중식 do-catch 블록으로 전파되도록 했습니다. 이 솔루션은 타입 안전성과 가독성을 균형 있게 유지했기 때문에 선택되었습니다. 명시적인 try 주석은 행복한 경로를 종료할 수 있는 작업에 대한 필수 문서 역할을 했습니다. 우리는 오류 처리 코드 양을 45% 줄였고, 수동 오류 축적 로직 없이 완전한 감사 추적을 달성했습니다.
enum MedicalRecordError: Error { case invalidJSON case signatureExpired case decryptionFailed } func processPatientRecord(_ input: Data) throws -> PatientRecord { let metadata = try parseMetadata(input) // 명시적 실패 지점 try validateSignature(metadata, input) // 보안 중요 가시성 return try decrypt(input, key: metadata.key) }
try?와 try!의 의미적 차이는 무엇이며, 왜 try?는 오류를 처리하기보다는 무시하나요?
후보자들은 종종 try?를 옵셔널 체이닝과 혼동하여 오류를 무시하는 안전한 방법이라고 생각합니다. 실제로 try?는 발생한 오류를 즉시 nil로 변환해 모든 진단 정보를 잃고, 복구 로직이 실행되는 것을 방지합니다. 이는 오류가 불가능하다고 주장하며 이 가정이 위반될 경우 런타임 함정을 트리거하는 try!와 근본적으로 다릅니다. 초보자는 try?가 특정 오류 유형이 무관하고 작업이 진정으로 선택적일 때만 적합하다는 점을 이해해야 하며, try!는 프로그램에서 결코 프로덕션으로 배포되어서는 안 되는 논리 오류를 나타냅니다.
rethrows 키워드는 고차 함수의 ABI 및 호출 규칙에 어떻게 영향을 미치며, 비 던지기 클로저를 전달할 때 try 없이 rethrows 함수를 호출할 수 있는 이유는 무엇인가요?
많은 후보자들은 rethrows를 단순한 문서로 보고 있지만, 실제로는 ABI 수준에서 조건부 함수 서명을 설정합니다. 함수가 rethrows로 표시되면, 컴파일러는 두 개의 입력 지점을 생성합니다: 하나는 던지는 경우를 위한 것이고 다른 하나는 던지지 않는 경우를 위한 최적화된 것입니다. 클로저 인수가 컴파일 시점에 던지지 않음을 증명하면, 호출자는 최적화된 경로를 호출하고 try 키워드를 생략할 수 있습니다. 이는 함수의 타입 시스템 계약이 오류가 발생하지 않음을 보장하기 때문입니다. 이 이중 ABI 접근 방식은 오류 발생 변환을 유연하게 유지하면서, 맵/필터 작업을 위한 제로 비용 추상화를 가능하게 합니다.
오류가 발생했을 때 defer 블록이 스택 언와인딩 중에 실행되는 이유는 무엇이며, 이러한 상호 작용이 catch 블록에서의 명시적 정리와 비교할 때 자원 안전성을 어떻게 보장하나요?
후보자들은 종종 defer가 정상적인 범위 종료 시에만 실행되거나, 발생한 오류가 defer 문을 우회한다고 잘못 생각합니다. 스위프트에서 defer 블록은 범위가 종료될 때마다 LIFO 순서로 실행될 것이 보장되며, 여기에는 오류 전파 스택 언와인딩이 포함됩니다. 이 구조적 보장은 defer 등록과 이후의 throw 사이에 획득된 자원이 항상 해제되도록 보장합니다. 이는 여러 catch 블록에서 중복된 수동 정리와 달리—리팩토링 시 누락될 위험이 있는—자원이 획득된 직후에 위치한 defer가 단일 지역 선언을 통해 안전한 불변 조건을 유지합니다.