Re: Objective C++ and ObjC exceptions
Re: Objective C++ and ObjC exceptions
- Subject: Re: Objective C++ and ObjC exceptions
- From: Kai Brüning <email@hidden>
- Date: Fri, 21 Sep 2007 21:35:39 +0200
>On 19 Sep 2007, at 20:47, Kai Brüning wrote:
>
>>Most of the restrictions concerning the mixture of ObjC and C++ I do understand well and consider more or less obvious. But there's one exception concerning exceptions: if an Objective C exception unrolls the stack, it does not clean up C++ objects on that stack, that is their destructors are not called. This is a real bad thing, because it practically disables use of the C++ RAII (resource acquisition is initialization) design pattern in any code which may see Objective C exceptions.
>
>Well, you need to catch exceptions and either throw a C++ wrapper exception or handle them before they exit a scope where you've used RAII. A bit of a pain, perhaps...
Hm, yes, only that I had the hope to be able to use smart pointers for retain count management. That is, instead of writing
id o = [AnObjCClass alloc] init];
... some substantial code ...
[o release];
and hoping that none of the code in between throws an exception and no maintainer ever inserts a return I could write
smartId o = [AnObjCClass alloc] init];
... some substantial code ...
and have the compiler guarantee that the destructor of 'o' does the release no matter what.
Now this makes little sense if I would have to wrap every Objective C call which could throw an exception (which are probably most of them) in a wrapper for exception conversion.
But than again, if I think about it, wrapping such calls in a catch block is necessary in the above example anyway to do the release, so maybe exception wrapping is a valid approach.
Another solution of this specific problem is of course an immediate autorelease, but that has its costs, too.
It's a pity, but I do understand the importance of backwards compatibility.
>
>>I am aware that there is probably no remedy, but I am so disappointed about this behavior that I hope to receive at least a good reason for it
>
>The good reason is that ObjC exception handling had to be backwards compatible with the previous macro-based exception handler system (which relies on setjmp() and longjmp()). The C++ exception mechanism doesn't work that way, at least not on Mac OS X.
>
>>and maybe some hope for change in the future. The not so near future, I am afraid, since I already tested with XCode 3 under Leopard.
>
>I don't suppose this is likely to be fixed for 32-bit apps any time soon. Apple *could* change longjmp() to unwind the stack, as Microsoft did on Windows, but that breaks some uses of setjmp()/longjmp() so it probably isn't the best idea (I think this is one reason Microsoft had to add "fibers").
Cooperative threads implemented using setjmp()/longjmp()? Interesting idea! And yes, stack unrolling would indeed break this real bad.
> And it doesn't fix other problems relating to exception handling and the RIAA pattern.
>
>For instance, it has never been safe throwing C++ exceptions through non-C++ code, because that code won't be able to clean up. The issue of throwing ObjC exceptions through C++ code is really one and the same problem, it's just that it's happening *to* C++ programmers rather than because of them.
Ok, sure, but than again the language is called Objective C++... Anyway, philosophical discussions won't change reality.
Thanks for the explanations!
Kai
_______________________________________________
Do not post admin requests to the list. They will be ignored.
Xcode-users mailing list (email@hidden)
Help/Unsubscribe/Update your Subscription:
This email sent to email@hidden