Re: Exception handling
Re: Exception handling
- Subject: Re: Exception handling
- From: Alastair Houghton <email@hidden>
- Date: Thu, 14 Jun 2018 10:03:06 +0100
On 14 Jun 2018, at 03:53, Quincey Morris <email@hidden>
wrote:
>
> On Jun 13, 2018, at 19:22 , Casey McDermott <email@hidden> 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 (email@hidden)
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:
This email sent to email@hidden