On 14 Jun 2018, at 03:53, Quincey Morris <quinceymor...@rivergatesoftware.com> wrote: > > 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.
Agreed, but with the proviso that the Cocoa framework actually catches and ignores exceptions itself in various contexts. This can be quite annoying when it happens, because it can result in odd behaviour and it isn’t always obvious that the cause was an exception. > 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. No, you aren’t out on your own. That’s the tradition in the Objective-C world; either return a nil or NO result with an NSError parameter filled in appropriately, or throw an exception where a crash is probably appropriate. There are a couple of places in the Cocoa frameworks where things don’t quite work that way; notably, Distributed Objects can throw exceptions when you send messages to remote objects — this makes sense, because the local proxy object is supposed to behave pretty much the same as the remote object, and could in general be of any type (therefore doesn’t necessarily have an NSError parameter available, or even a return code that could be used to indicate failure). If you’re using DO, you might therefore use Objective-C exceptions for some recoverable error handling (e.g. where a remote server has “gone away” and you therefore need to reconnect somehow or connect somewhere else). > 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. More to the point, there’s nowhere safe to catch uncaught exceptions; you can’t assume that you can safely throw a C++ exception through any library or framework, including the Cocoa and Core Foundation frameworks, even though on the 64-bit runtime Objective-C and C++ exceptions are (kind of) unified, because Objective-C code generally doesn’t expect exceptions and so if you throw them through it it’s unlikely to be in a good state afterwards. Basically, if you’re calling C++ code from your Objective-C code, and that C++ code might throw exceptions, you’re going to want to call it within a try statement (you *can* use an Objective-C @try, in which case the @catch(…) case will catch C++ exceptions; but that probably won’t give you the granularity you want). Kind regards, Alastair. -- http://alastairs-place.net _______________________________________________ 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
