• Open Menu Close Menu
  • Apple
  • Shopping Bag
  • Apple
  • Mac
  • iPad
  • iPhone
  • Watch
  • TV
  • Music
  • Support
  • Search apple.com
  • Shopping Bag

Lists

Open Menu Close Menu
  • Terms and Conditions
  • Lists hosted on this site
  • Email the Postmaster
  • Tips for posting to public mailing lists
Re: Objective-C++ Exceptions (was: PICT control problems)
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Objective-C++ Exceptions (was: PICT control problems)


  • Subject: Re: Objective-C++ Exceptions (was: PICT control problems)
  • From: Thomas Engelmeier <email@hidden>
  • Date: Wed, 28 Jun 2006 13:05:00 +0200

If your application encounters an NSException, then the state of the AppKit, Foundation, and CoreData are undefined. NSExceptions are thrown for non-recoverable runtime errors.

NACK. There are NSExceptions e.g. when you try to put nil values into an NSMutableDictionary or exceed NSArray bounds. Not that one should not fix this, but I do not see the point an application should just burn down and loose every other data when that happens - like most Cocoa applications do.


In contrary to C++ application where it is IMO more widespread (and trained - see Scott Meyers Exceptional C++ and More EC++) to use an exception to indicate a whole "transaction" has failed and roll back to the last stable state. (Exception-Safe programming).

And, yes, as you indicate this becomes a much bigger problem when you are working with a third party framework or library whose design pattern goes against this model of exceptions-only-indicate- runtime-nonrecoverable-errors.

Like, say, Foundation.framework?

I'm not discounting the problem. Not in the least. I am trying to draw attention to a different dimension of the problem that, unless acknowledged and addressed, will lead to code that doesn't work no matter how "normalized" the Obj-C vs. C++ exception handling might be.

Well, I'd dare to say that the typical Cocoa design patterns do not have graceful error RECOVERY in mind. Handling to an extend that subsequent operations on the results silently fail - yes. But for an recovery something like an failure reason'd be required, and thats more the C / C++ paradigma.


Regards,
Tom_E _______________________________________________
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
  • Follow-Ups:
    • Re: Objective-C++ Exceptions (was: PICT control problems)
      • From: Tommy Nordgren <email@hidden>
References: 
 >PICT control problems (From: John Lunt <email@hidden>)
 >Re: PICT control problems [SOLVED] (From: John Lunt <email@hidden>)
 >Re: PICT control problems [SOLVED] (From: Scott Thompson <email@hidden>)
 >Re: PICT control problems [SOLVED] (From: John Lunt <email@hidden>)
 >Re: PICT control problems [SOLVED] (From: Markus Hitter <email@hidden>)
 >Re: PICT control problems [SOLVED] (From: John Lunt <email@hidden>)
 >Re: PICT control problems [SOLVED] (From: Bill Bumgarner <email@hidden>)
 >Re: PICT control problems [SOLVED] (From: Marshall Clow <email@hidden>)
 >Re: PICT control problems [SOLVED] (From: Bill Bumgarner <email@hidden>)
 >Objective-C++ Exceptions (was: PICT control problems) (From: Steve Sisak <email@hidden>)
 >Re: Objective-C++ Exceptions (was: PICT control problems) (From: Bill Bumgarner <email@hidden>)

  • Prev by Date: Re: error : forward declaration of 'struct MYSprite'
  • Next by Date: Re: Objective-C++ Exceptions (was: PICT control problems)
  • Previous by thread: Re: Objective-C++ Exceptions (was: PICT control problems)
  • Next by thread: Re: Objective-C++ Exceptions (was: PICT control problems)
  • Index(es):
    • Date
    • Thread