ném một ngoại lệ trong mục tiêu-c/ca cao

Question

Cách tốt nhất để ném ngoại lệ trong mục tiêu-c/ca cao là gì?

Answer 1

tôi sử dụng [NSException raise:format:] như sau:

[NSException raise:@"Invalid foo value" format:@"foo of %d is invalid", foo];

Answer 2

@throw([NSException exceptionWith…]) 

Answer 3

Tôi nghĩ rằng để được nhất quán nó đẹp hơn để sử dụng @throw với lớp của riêng bạn mà kéo dài NSException. Sau đó, bạn sử dụng các ký hiệu tương tự cho cố gắng nắm bắt cuối cùng:

@try { 
..... 
} 
@catch{ 
... 
} 
@finally{ 
... 
} 

Apple giải thích ở đây làm thế nào để ném và xử lý các trường hợp ngoại lệ: Catching Exceptions Throwing Exceptions

Answer 4

Một lời cảnh báo ở đây. Trong mục tiêu-C, không giống như nhiều ngôn ngữ tương tự, bạn thường nên cố gắng tránh sử dụng các ngoại lệ cho các tình huống lỗi phổ biến có thể xảy ra trong hoạt động bình thường.

Apple's documentation for Obj-C 2.0 tiểu bang như sau: "Chú ý: Trường hợp ngoại lệ là tài nguyên-chuyên sâu trong Objective-C Bạn không nên sử dụng các ngoại lệ cho điều khiển luồng chung, hoặc chỉ đơn giản là để biểu thị lỗi (chẳng hạn như một tập tin không được truy cập)."

Apple's conceptual Exception handling documentation giải thích tương tự, nhưng với nhiều từ hơn: "Quan trọng: Bạn nên đặt trước việc sử dụng ngoại lệ cho lập trình hoặc lỗi thời gian chạy không mong muốn như truy cập bộ sưu tập ngoài giới hạn, cố gắng thay đổi đối tượng không thay đổi, gửi thư không hợp lệ và mất kết nối với máy chủ cửa sổ. Bạn thường xử lý các loại lỗi này với các ngoại lệ khi một ứng dụng đang được tạo chứ không phải lúc chạy. [.....] Thay vì ngoại lệ, các đối tượng lỗi (NSError) và lỗi Cocoa cơ chế phân phối là cách được khuyến nghị để truyền đạt lỗi dự kiến ​​trong ứng dụng Cocoa. "

Lý do cho việc này một phần là tuân thủ các thành ngữ lập trình trong Mục tiêu-C (sử dụng giá trị trả về trong trường hợp đơn giản và tham số tham chiếu (thường là lớp NSError) trong trường hợp phức tạp hơn) đắt hơn và cuối cùng (và perpaps quan trọng nhất) rằng trường hợp ngoại lệ Objective-C là một wrapper mỏng xung quanh C của setjmp() và longjmp() chức năng, về cơ bản rối tung lên xử lý bộ nhớ cẩn thận của bạn, xem this explanation.

Answer 5

Tôi không có đại diện để nhận xét về phản hồi của eJames, vì vậy tôi đoán tôi cần phải đưa tôi vào đây. Đối với những người đến từ một nền Java, bạn sẽ nhớ lại rằng Java phân biệt giữa Exception và RuntimeException. Ngoại lệ là một ngoại lệ được kiểm tra, và RuntimeException được bỏ chọn. Cụ thể, Java đề xuất sử dụng các ngoại lệ đã kiểm tra cho "các điều kiện lỗi bình thường" và các ngoại lệ không được kiểm tra cho "lỗi thời gian chạy do lỗi lập trình viên gây ra". Dường như các ngoại lệ Objective-C nên được sử dụng trong cùng một vị trí bạn sẽ sử dụng một ngoại lệ không được kiểm soát và các giá trị trả về mã lỗi hoặc các giá trị NSError được ưu tiên ở những nơi bạn sẽ sử dụng một ngoại lệ đã kiểm tra.

Answer 6

Tôi tin rằng bạn không bao giờ nên sử dụng Ngoại lệ để kiểm soát luồng chương trình thông thường. Nhưng ngoại lệ nên được ném bất cứ khi nào một số giá trị không khớp với giá trị mong muốn.

Ví dụ, nếu một số chức năng chấp nhận một giá trị, và giá trị mà không bao giờ được phép có con số không, sau đó nó là tốt để TROW một ngoại lệ chứ không phải sau đó cố gắng để làm điều gì đó 'thông minh' ...

Ries

Answer 7

Kể từ ObjC 2.0, trường hợp ngoại lệ Objective-C là không còn là một wrapper cho setjmp C() longjmp(), và tương thích với C++ ngoại lệ, các @try là "miễn phí", nhưng ném và bắt ngoại lệ là cách tốn kém hơn.

Dù sao, xác nhận (sử dụng NSAssert và NSCAssert macro family) ném NSException, và sane để sử dụng chúng như là trạng thái Ries.

Answer 8

Không có lý do không sử dụng ngoại lệ bình thường trong quan C thậm chí để biểu thị trường hợp ngoại lệ quy tắc kinh doanh. Apple có thể nói sử dụng NSError người quan tâm. Obj C đã được khoảng một thời gian dài và tại một thời gian ALL C + + tài liệu cho biết điều tương tự. Lý do nó không vấn đề như thế nào đắt ném và bắt một ngoại lệ là, là cuộc đời của một ngoại lệ là cực kỳ ngắn và ... một EXCEPTION của mình cho dòng chảy bình thường. Tôi chưa bao giờ nghe bất cứ ai nói trong cuộc đời của tôi, người đàn ông ngoại lệ đó mất một thời gian dài để bị ném và bị bắt.

Ngoài ra, có những người nghĩ rằng mục tiêu C chính nó là quá đắt và mã trong C hoặc C++ thay thế. Vì vậy, nói rằng luôn luôn sử dụng NSError là không thông tin và hoang tưởng.

Nhưng câu hỏi của chủ đề này vẫn chưa được trả lời cách tốt nhất để ném một ngoại lệ. Các cách để trả về NSError là hiển nhiên.

Vậy là: [NSException raise: ... @throw [[NSException alloc] initWithName .... hoặc @throw [[MyCustomException ...?

tôi sử dụng kiểm tra/quy tắc không được kiểm soát ở đây hơi khác biệt so với ở trên.

Sự khác biệt thực sự giữa (sử dụng phép ẩn dụ java ở đây) được kiểm tra/bỏ chọn là quan trọng -> cho dù bạn có thể phục hồi từ ngoại lệ. Và bằng cách phục hồi tôi có nghĩa là không chỉ không sụp đổ.

Vì vậy, tôi sử dụng các lớp ngoại lệ tùy chỉnh với @throw cho các trường hợp ngoại lệ có thể phục hồi, vì khả năng tôi sẽ có một số phương pháp ứng dụng tìm các loại lỗi nhất định trong nhiều khối @catch. Ví dụ, nếu ứng dụng của tôi là một máy ATM, tôi sẽ có một khối @catch cho "WithdrawalRequestExceedsBalanceException" .

Tôi sử dụng NSException: nâng cao ngoại lệ thời gian chạy vì tôi không có cách nào để khôi phục ngoại lệ, ngoại trừ để bắt nó ở cấp cao hơn và ghi nhật ký. Và theres không có điểm trong việc tạo ra một lớp học tùy chỉnh cho điều đó.

Dù sao thì cũng như những gì tôi làm, nhưng nếu có cách tốt hơn, tương tự như tôi muốn biết nữa. Trong mã của riêng tôi, vì tôi đã ngừng mã hóa C a hella từ lâu rồi nên tôi không bao giờ trả về NSError ngay cả khi tôi được chuyển qua một API.

Answer 9

Sử dụng NSError để giao tiếp lỗi thay vì ngoại lệ.

điểm nhanh về NSError:

• NSError cho phép mã lỗi C phong cách (số nguyên) để xác định rõ nguyên nhân gốc rễ và hy vọng cho phép xử lý lỗi để khắc phục lỗi. Bạn có thể bọc mã lỗi từ các thư viện C như SQLite trong các cá thể NSError rất dễ dàng.

• NSError cũng có lợi ích là một đối tượng và cung cấp cách mô tả lỗi chi tiết hơn với thành viên từ điển userInfo của nó.Tuy nhiên, tốt nhất của tất cả, NSError KHÔNG THỂ được ném để nó khuyến khích một cách tiếp cận chủ động hơn để xử lý lỗi, trái ngược với các ngôn ngữ khác mà chỉ đơn giản là ném khoai tây nóng hơn nữa và tiếp tục lên các cuộc gọi ngăn xếp tại thời điểm đó nó chỉ có thể được báo cáo cho người dùng và không được xử lý theo bất kỳ cách nào có ý nghĩa (không phải nếu bạn tin vào việc tuân thủ nguyên lý thông tin lớn nhất của OOP đang ẩn).

tham khảo Link: Reference

Answer 10

Bạn có thể sử dụng hai phương pháp để nâng cao ngoại lệ trong khối try catch

@throw[NSException exceptionWithName]; 

hoặc phương pháp thứ hai

NSException e; 
[e raise]; 

Answer 11

Đây là cách tôi đã học được nó từ "Hướng dẫn Ranch Big Nerd (ấn bản thứ 4)":

@throw [NSException exceptionWithName:@"Something is not right exception" 
           reason:@"Can't perform this operation because of this or that" 
          userInfo:nil]; 

Answer 12

Bạn chỉ nên ném ngoại lệ nếu bạn thấy mình trong tình huống cho biết lỗi lập trình và muốn ngừng chạy ứng dụng. Vì vậy, cách tốt nhất để ném ngoại lệ là sử dụng các macro NSAssert và NSParameterAssert, và đảm bảo rằng NS_BLOCK_ASSERTIONS không được định nghĩa.

Answer 13

Mẫu mã đối với trường hợp: @throw ([NSException exceptionWithName: ...

- (void)parseError:(NSError *)error 
     completionBlock:(void (^)(NSString *error))completionBlock { 


    NSString *resultString = [NSString new]; 

    @try { 

    NSData *errorData = [NSData dataWithData:error.userInfo[@"SomeKeyForData"]]; 

    if(!errorData.bytes) { 

     @throw([NSException exceptionWithName:@"<Set Yours exc. name: > Test Exc" reason:@"<Describe reason: > Doesn't contain data" userInfo:nil]); 
    } 


    NSDictionary *dictFromData = [NSJSONSerialization JSONObjectWithData:errorData 
                   options:NSJSONReadingAllowFragments 
                    error:&error]; 

    resultString = dictFromData[@"someKey"]; 
    ... 


} @catch (NSException *exception) { 

      NSLog(@"Caught Exception Name: %@", exception.name); 
      NSLog(@"Caught Exception Reason: %@", exception.reason); 

    resultString = exception.reason; 

} @finally { 

    completionBlock(resultString); 
} 

}

Sử dụng:

[self parseError:error completionBlock:^(NSString *error) { 
      NSLog(@"%@", error); 
     }]; 

Một use-case cao cấp hơn:

- (void)parseError:(NSError *)error completionBlock:(void (^)(NSString *error))completionBlock { 

NSString *resultString = [NSString new]; 

NSException* customNilException = [NSException exceptionWithName:@"NilException" 
                  reason:@"object is nil" 
                 userInfo:nil]; 

NSException* customNotNumberException = [NSException exceptionWithName:@"NotNumberException" 
                   reason:@"object is not a NSNumber" 
                   userInfo:nil]; 

@try { 

    NSData *errorData = [NSData dataWithData:error.userInfo[@"SomeKeyForData"]]; 

    if(!errorData.bytes) { 

     @throw([NSException exceptionWithName:@"<Set Yours exc. name: > Test Exc" reason:@"<Describe reason: > Doesn't contain data" userInfo:nil]); 
    } 


    NSDictionary *dictFromData = [NSJSONSerialization JSONObjectWithData:errorData 
                   options:NSJSONReadingAllowFragments 
                    error:&error]; 

    NSArray * array = dictFromData[@"someArrayKey"]; 

    for (NSInteger i=0; i < array.count; i++) { 

     id resultString = array[i]; 

     if (![resultString isKindOfClass:NSNumber.class]) { 

      [customNotNumberException raise]; // <====== HERE is just the same as: @throw customNotNumberException; 

      break; 

     } else if (!resultString){ 

      @throw customNilException;  // <====== 

      break; 
     } 

    } 

} @catch (SomeCustomException * sce) { 
    // most specific type 
    // handle exception ce 
    //... 
} @catch (CustomException * ce) { 
    // most specific type 
    // handle exception ce 
    //... 
} @catch (NSException *exception) { 
    // less specific type 

    // do whatever recovery is necessary at his level 
    //... 
    // rethrow the exception so it's handled at a higher level 

    @throw (SomeCustomException * customException); 

} @finally { 
    // perform tasks necessary whether exception occurred or not 

} 

}