将 Java 转换为 Objective-C:异常处理

发布于 2024-09-10 04:14:14 字数 217 浏览 7 评论 0原文

我正在将 Java 库转换为 Objective-C。 Java 代码明目张胆地使用异常(以我习惯于 Objective-C 的思维)。转换时,我应该抛出 Objective-C 异常(仅在库内;我会在它们离开之前捕获它们)还是应该使用 NSError 构造。

我熟悉常规 Objective-C 代码中异常的用例;即仅针对真正异常的错误。如果我在这里没有得到明确的答案,我可能会使用 NSErrors。

I'm converting a Java library to Objective-C. The Java code uses exceptions flagrantly (to my Objective-C accustomed mind). When converting, should I be throwing Objective-C exceptions (only within the library; I'll catch them before they leave) or should I use NSError constructs.

I'm familiar with the use-case for exceptions in regular Objective-C code; i.e. only for truly exceptional errors. If I don't get a definitive answer here, I'll probably use NSErrors.

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(4

始终不够 2024-09-17 04:14:14

在 Objective-C 中抛出和捕获异常是昂贵的(除了在 32 位 Mac OS X 上,其中异常捕获代码的 @try 部分是昂贵的部分,而不是 @catch 部分。)

您最好以某种机制返回错误代码(例如 NSError,Objective-C 中的面向对象方法。)让这些冒泡到以下代码:访问您的框架,然后让代码适当地处理它。

任何一个系统出现错误时的内存清理都不应该是一个大问题,因为您应该能够将大多数对象和分配放入自动释放池中。但是,请注意,池将耗尽在其范围内创建的任何 NSErrorNSException 对象,因此您必须确保这些对象在您的对象结束后仍然存在。带有额外保留和释放的代码。 (有点偏离主题,但我看到很多人在进行错误处理时搞砸了这部分。)

Throwing and catching exceptions in Objective-C is expensive (except on 32-bit Mac OS X, where the @try part of the exception-catching code is the expensive part instead of the @catch part.)

You're better off returning error codes in some mechanism (such as NSError, the OO way to do it in Objective-C.) Let those bubble up to the code that accesses your framework, and then let that code handle it appropriately.

Memory cleanup in the case of error with either system should not be a huge worry, as you should be able to put most objects and allocations in an autorelease pool. However, be advised that the pool will eat up any NSError or NSException objects created within its scope, so you'll have to make sure those objects survive past the end of your code with additional retains and releases. (Slightly off-topic, but I've seen a lot of people screw this part up when doing error handling.)

笑脸一如从前 2024-09-17 04:14:14

如果库可以自己处理所有异常,那么它们就不是 Objective-C 意义上的真正异常:没有发生程序员错误;相反,完全预料到的事情已经发生了。您应该根据需要使用错误代码/NSError,但您也许能够处理异常提供的大部分信息,并仅返回一个指示“错误”的值(nil、0 和 NSNotFound 是一些常见的)并处理它。您还可以考虑错误处理委托方法。

If the library can handle all the exceptions on its own, then they're not really exceptions in the Objective-C sense of the word: no programmer error has occurred; rather, something wholly anticipated has happened. You should use use error codes/NSError as needed, but you might be able to dispose with much of the info provided by the exceptions and just return a value that indicates an "error" (nil, 0, and NSNotFound being some of the common ones) and handle that. You might also consider error-handling delegate methods.

自找没趣 2024-09-17 04:14:14

我只会返回 Objective-C 库上的错误(NSError 方法)。毕竟,这是 C 中完成错误处理的方式。

I would just return errors on the Objective-C library (NSError approach). After all, it's the way error handling is done in C.

拿命拼未来 2024-09-17 04:14:14

我不会太担心使用或不使用异常。如果它使您的代码更清晰,请使用它们。您真正需要注意的唯一一件事是不要通过您不知道异常安全的代码抛出异常,这几乎是您没有编写的所有代码。

是的,使用异常的成本很高,但担心这一点是过早优化的一个例子。毕竟,与 C 函数调用相比,Objective-C 消息调度的成本很高,但你不会听到 Objective-C 程序员说“不要使用 Objective-C 消息”。

I wouldn't worry too much about using or not using exceptions. If it makes your code cleaner, use them. The only thing you really have to be careful about is not throwing exceptions through code that you do not know is exception safe which is pretty much all code you did not write.

Yes, using exceptions is expensive, but worrying about that is an example of premature optimisation. After all, compared with a C function call, Objective-C message dispatch is expensive, but you don't hear Objective-C programmers saying "don't use Objective-C messages".

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文