오류 처리 또는 예외 처리를 사용해야하는 위치를 이해할 수 없습니다. 나는 이것이 기존의 프레임 워크 클래스라면 프로그래머가 오류 객체 참조를 보내고 그 후에 오류를 처리하는 것을 용이하게하는 델리게이트 메소드가 있다고 가정한다. 예외 처리는 일부 프레임 워크 클래스를 사용하는 프로그래머가 오류를 throw하고 오류 객체의 참조에 대한 수정을 얻을 수없는 경우를위한 것입니다.오류 처리 대 대상 c의 예외 처리
이 가정은 유효합니까? 또는 어떻게 이해해야합니까?
프로그래머가 예외를 throw하는 메서드의 매개 변수를 검사하면 오류가 나타나지 않도록 예외를 사용해야합니다. 예 : NSArrays에서 얻은 0 또는 잘 알려진 "out of bounds"예외로 나눕니다.
NSErrors는 프로그래머가 아무 것도 할 수없는 오류입니다. 예 : plist 파일을 구문 분석합니다. 프로그램이 내용을 읽으려고 시도하기 전에 파일이 유효한 plist인지 확인하는 경우 자원 낭비 일 수 있습니다. 유효성 검사를 위해 프로그램은 전체 파일을 구문 분석해야합니다. 그리고 파일을 구문 분석하여 유효하다고보고하면 다시 파싱 할 수 있으므로 낭비가됩니다. 따라서이 메서드는 파일을 구문 분석 할 수없는 경우 NSError (또는 무언가 잘못되었다는 것을 알려주는 nil)를 반환합니다.
유효성에 대한 구문 분석은 "프로그래머가 매개 변수를 확인 했어야합니다"부분입니다. 이 오류 유형에는 적용 할 수 없으므로 예외를 throw하지 않습니다.
이론적으로 예외 범위 예외는 return nil으로 바꿀 수 있습니다. 그러나 이것은 매우 나쁜 프로그래밍으로 이어질 것입니다.
Apple는 말한다 :
중요 : 많은 환경에서는 예외의 사용은 매우 평범하다. 예를 들어 파일이 누락되었거나 데이터를 올바르게 파싱 할 수없는 경우와 같이 루틴이 정상적으로 실행될 수 없음을 알리는 예외를 throw 할 수 있습니다. 예외는 Objective-C에서 자원 집약적입니다. 일반 흐름 제어에 예외를 사용하거나 단순히 오류를 나타내지 말아야합니다. 대신 메서드 또는 함수의 반환 값을 사용하여 오류가 발생했음을 나타내야하며 오류 개체의 문제에 대한 정보를 제공해야합니다.
나는 당신이 오류에 대한 가정과 절대적으로 맞다고 생각한다. 그리고 프레임 워크는 (UIWebView 오류 처리) 일련의 방법을 제공한다. 그러나 우리가 틀린 일을 할 경우에만 예외가 발생하기 때문에 예외적으로 당신의 가정은 부분적으로 옳다. 프레임 워크에 의해 허용되고 고정 될 수있다. (예를 들어 배열의 멤버를 한도를 넘어 액세스하는 경우). 이며 응용 프로그램이 중단됩니다.