Swift는 2.0 버전에서 구조화된 오류 처리를 도입하여 Objective-C의 오류 포인터 패턴을 본래의 throw 및 catch 의미론으로 대체했습니다. rethrows 키워드는 map 또는 filter와 같은 일반 고차 함수가 비던지기 클로저를 전달할 때도 호출자가 try를 사용해야 하는 불편함을 해결하기 위해 등장했습니다. 이는 불필요한 오류 처리 의식을 발생시킵니다.
문제는 함수 효과 다형성과 하위 타입에 중심을 둡니다. Swift의 타입 시스템에서는 비던지기 클로저가 던지기 클로저의 하위 타입으로 간주됩니다. 이는 결코 던지지 않기 때문에 "던질 수 있음" 계약을 만족합니다. rethrows가 없으면, 던지기 클로저를 받는 함수는 무조건적으로 오류를 전파해야 하며, 실제 인수의 동작과 상관없이 모든 호출 지점이 오류를 처리해야 합니다.
해결책은 rethrows 주석으로, 이는 조건부 계약을 설정합니다: 함수는 클로저 매개변수가 던질 때만 오류를 던집니다. Swift 컴파일러는 컴파일 시간에 클로저 인수의 던짐 여부를 추적하여 이를 구현합니다. 비던지기 클로저가 전달되면, 함수는 호출 지점에서 비던지기로 처리되어 try가 필요 없어집니다. 던지기 클로저가 전달되면, 함수는 던지는 효과를 상속받습니다.
우리는 사용자가 JSON 파싱, 이미지 크기 조정 및 암호화 해시와 같은 작업을 연결할 수 있는 모듈형 데이터 변환 파이프라인을 구축하고 있었습니다. 핵심 pipeline 함수는 (Data) throws -> Data로 정의된 변환 배열을 수용했습니다. 처음에는 pipeline에 표준 throws 주석을 사용했으며, 이는 모든 호출 지점을 심지어 단순 변환일지라도 do-catch 블록으로 감싸도록 강제했습니다. 많은 작업이 실패 모드가 없는 순수 함수이기 때문입니다.
첫 번째 접근 방식은 전체 함수를 복제했습니다. 비던지기 변환을 위한 pipeline이라는 버전과 던지기 변환을 위한 pipelineThrowing이라는 다른 버전이었습니다. 이 분리가 깨끗한 호출 지점을 가능하게 했지만, 모든 버그 수정을 위해 두 위치를 수정해야 했기에 유지보수의 악몽이 되었습니다. 새로운 구성 옵션이 추가될 때마다 API 표면이 두 배로 증가했습니다. 또한 사용자는 올바른 메서드를 선택하기 위해 구현 세부 정보를 알고 있어야 하며, 이는 캡슐화 원칙을 위반합니다.
두 번째 접근 방식은 단일 throws 시그니처를 유지하고 try?를 사용하여 경고를 숨기도록 장려했습니다. 이는 효과적으로 오류 정보를 버리고 실제 오류가 발생했을 때 디버깅을 불가능하게 만들었습니다. 이는 안전 보증을 위반하고 코드의 취약성을 가져왔으며, 개발자들이 안전 및 비안전 작업이 혼합된 파이프라인에서 진짜 오류 사례를 처리하는 것을 잊게 만들었습니다.
궁극적으로 우리는 rethrows 솔루션을 채택하여 func pipeline(_ transforms: [(Data) throws -> Data]) rethrows -> Data를 선언했습니다. 이는 컴파일러가 배열에 던지는 작업이 포함될 때만 try를 강제하도록 하여 순수 계산을 위한 직접 호출을 허용했습니다. 그 결과는 보일러플레이트 코드의 40% 감소, 중복 함수 시그니처의 제거, 특정 사용 사례의 실제 오류 도메인을 정확하게 반영한 API 사용성 향상이었습니다.
Swift가 rethrows 함수 본체 내에서 직접적으로 오류를 던지는 것을 금지하는 이유는 무엇인가?
rethrows 키워드는 함수가 인수에서 발생된 오류만 전파한다고 엄격한 투명성 계약을 만듭니다. 함수 본체 내에서 throw CustomError()를 시도할 경우 Swift 컴파일러는 이를 거부합니다. 이는 무조건적인 던지기를 나타내며, "클로저가 던질 때만"이라는 보증을 위반합니다. 함수는 내부적으로 오류를 처리하거나 반환 값으로 변환해야 하며, 또는 무조건 throws로 시그니처를 확대해야 하여 호출자가 함수 자체에서 새로운 오류 도메인이 발생하지 않는다고 안전하게 가정할 수 있도록 보장해야 합니다.
여러 클로저 매개변수와의 rethrows 상호작용은 어떻게 이루어지며, 효과 전파에 대한 의미는 무엇인가?
함수가 던지기 매개변수로 여러 개의 클로저를 가지고 있으며 함수 자체가 rethrows로 표시되면, 함수는 어떤 클로저가 던질 경우에도 오류를 던집니다. 이는 효과의 합집합을 만듭니다. Swift의 컴파일러는 호출 체인을 통해 이러한 효과를 개별적으로 추적하므로 rethrows 함수를 조합해도 수동 개입 없이 조건부 성질이 유지됩니다. 그러나 클로저를 전달하기 전에 변환하거나 포장하는 경우, 포장 안에서 던지기 시그니처를 유지해야 하며, 그렇지 않으면 컴파일러는 인수를 비던지기로 간주하여 외부 함수가 조건부 던지기 기능을 잃어버리는 결과가 됩니다.
rethrows와 @autoclosure 간의 관계는 무엇이며, 이 패턴이 검증 API에서 나타나는 이유는 무엇인가?
@autoclosure와 rethrows의 조합은 조건부 오류 전파와 함께 지연 평가를 가능하게 하며, 여기서 자동 클로저는 필요할 때까지 평가를 지연시키고 함수는 지연 평가가 던질 때만 오류를 던집니다. 이 패턴은 Swift의 assert 및 precondition 함수에서 발생하여, 던짐 표현식을 Assertions에 전달할 수 있게 해 주며, Assertion 호출에 try를 표시할 필요가 없습니다. 후보자들은 자동 클로저가 () throws -> T로 명시적으로 선언되어야 rethrows 계약에 참여할 수 있다는 사실과 이 메커니즘이 평가 시기는(지연) 오류 전파 의미론(조건부)와 분리된다는 점을 자주 놓칩니다. 이는 릴리스 빌드에서 Assertions가 비활성화될 때 성능이 중요한 코드 경로에서 매우 중요합니다.