On Mar 21, 2011, at 7:24 PM, Chris Hanson wrote: > The reason is that if your exception crosses any stack frame you don’t fully > control, all bets are off when it comes to the state of your program. The > frameworks have all been written with the assumption that exceptions are only > for catastrophic (non-recoverable) failures, and that the only way to respond > to an exception is to terminate the application as gracefully as possible.
Not sure I agree that this is a good reason. Prior to Mac OS X, I wrote a lot of Carbon code with callbacks in C++. I understood the need to install a top (callback)-level exception handler to ensure the exceptions weren't propagated back into unaware code. I did this frequently and successfully. Cocoa's approach effectively forbids exceptions as a convenient and elegant exceptional-condition-handling mechanism, yet the occasional use within Cocoa itself means I still have to deal with the consequences. Moreover, since exceptions did work across forward invocations prior to Cocoa Touch and 64-bit Mac OS X, I think it is reasonable to assume they should still work. In the meantime, I've modified HessianKit to catch exceptions and return them as a return parameter, and all my instances of calling RPC methods now check their return parameter to see if it's an exception. What I had before was better: not only could I catch exceptions in HessianKit (like network errors), I was also able to catch exceptions thrown in the Java server. It was pretty cool. -- Rick _______________________________________________ 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: http://lists.apple.com/mailman/options/cocoa-dev/archive%40mail-archive.com This email sent to arch...@mail-archive.com
