On Jun 13, 2018, at 19:22 , Casey McDermott <supp...@turtlesoft.com> wrote:
> 
> Nearly always, the event loop is the best place to escape to.


This is not how current thinking goes, unless you mean something different from 
what I think you’re saying.

If you’re implementing sanity (“should not happen”) checks, then the belief 
that it’s safe to shrug and return to the event loop is just false. It would be 
true if no significant state was preserved across event loop iterations, but 
that’s not nearly true — and likely extremely *un*true for those APIs and 
libraries that are complicated enough for the checks to fail sometimes. It’s 
simply not safe to branch out of lower-level code unless *all* of the code has 
been explicitly designed for that usage style.

It’s better to simply log the error and crash.

For recoverable errors in Obj-C code, you’re better off just doing the work of 
returning a “success or not” value along with a NSError out parameter. It’s a 
bit of grunt work to add this to existing code, but it’s probably worthwhile. 
(This would include having failable class init’s that have an outError 
parameter, which is not a common pattern, though it should be.)

The real problem comes, however, when you consider multiple threads. You can 
certainly catch NSExceptions in a sendEvent: override on the main thread, but 
in modern Cocoa programming there are many situations where you’re running your 
code on a background thread (e.g. GCD), and there’s not always an event loop or 
any good place to catch exceptions.

The situation with C++ exceptions is a bit different. You can basically do 
whatever you want with those (including using them for flow control), but 
there’s still nowhere central to catch uncaught exceptions, and you still have 
to worry about multithreading.

I may be out on my lonesome here, but if you want a robust app, I really think 
you have exactly 2 error handling patterns:

1. Returning false/nil with an outError parameter for recoverable errors, and 
always testing the result at every level.

2. Throwing NSExceptions for unrecoverable errors, and letting the app crash 
immediately.


_______________________________________________

Cocoa-dev mailing list (Cocoa-dev@lists.apple.com)

Please do not post admin requests or moderator comments to the list.
Contact the moderators at cocoa-dev-admins(at)lists.apple.com

Help/Unsubscribe/Update your Subscription:
https://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com

This email sent to arch...@mail-archive.com

Reply via email to