• 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: Bill Bumgarner <email@hidden>
  • Date: Wed, 28 Jun 2006 11:16:33 -0700

(This is from a discussion on xcode-users that is really a Cocoa discussino).

On Jun 28, 2006, at 4:05 AM, Thomas Engelmeier wrote:
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.

Yeah -- you are right. I had my journalist hat on and made an unwarranted "sky is falling" level remark.


As you say, such simple exception raising situations should be fixed...

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.

Depends on the type of error.

Cocoa chooses to treat programmer error as a non-recoverable situation. This is done for safety's sake. At the point in time that some bit of model code causes an "index out of bounds" exception, it may very likely have been during changes to that model and the raising of the exception has now rendered the model's object graph invalid. Saving the model will not help unless the saving code has significant validation and error recovery capabilities. Better to fix the programmer error in the first place and not allow the code to toss the exception.

http://developer.apple.com/documentation/Cocoa/Conceptual/Exceptions/ Exceptions.html

For user error, Cocoa has extensive detection and handling capabilities. At the user interface level, formatters can be used to validate and limit user input. At the lower level, KVC offers validation features that can be exercised manually. Core Data extends this behavior by offering automatic validation.

http://developer.apple.com/documentation/Cocoa/Conceptual/ KeyValueCoding/Concepts/Validation.html#//apple_ref/doc/uid/20002173


_______________________________________________ Do not post admin requests to the list. They will be ignored. Cocoa-dev mailing list (email@hidden) Help/Unsubscribe/Update your Subscription: This email sent to email@hidden
  • Prev by Date: Idle-time processing in a runloop
  • Next by Date: Newb question, Website for Syntax search lookup ?
  • Previous by thread: Re: Objective-C++ Exceptions (was: PICT control problems)
  • Next by thread: Multiple nib files in a core data app
  • Index(es):
    • Date
    • Thread