• 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: Error and Exception Handling: When to use
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Error and Exception Handling: When to use


  • Subject: Re: Error and Exception Handling: When to use
  • From: Ryan Homer <email@hidden>
  • Date: Tue, 12 Jun 2007 11:48:42 -0400

It seems like at one time error handling was done primarily via the NSError class and that more recently Apple has been trying to introduce exception handling, but it seems that a Cocoa application may have to use a mix of error handling. If, for example, you are using a class method that is NOT documented to throw an exception for an error you anticipate, then you'll have to handle it otherwise.

In general C++ programming (I don't know how this applies to Objective-C and the Cocoa platform), if you decide to use exceptions in your class, you generally throw an exception and not worry any more about it. The person using your call will need to catch that error if s/he wants to handle it, perhaps re-throw it, etc. This is especially true if your class has nothing to do with the user interface, i.e. it falls within the "model" category of MVC programming. Since you do not know how your user wants to display this error in the view, you simply throw the exception.

I do not agree that exception handling is only for serious/fatal situations. The whole idea is to flag in the application that there is some kind of error and let the exception be thrown and re-thrown as seen fit until the appropriate part of the application can handle it. If it is not a very serious error and you don't want to handle it after catching it, you simple don't rethrow it.

One thing that you do have to look out for is not catching the error at all; this can happen in your catch statement specifies a specific type of exception class that you want to catch and the exception class thrown is of a more general type (a super class). If the exception is not handled at all, I think NSApplication will catch it, show the error as an Application crash and close the app, unless you've implemented the NSSetUncaughtExceptionHandler function.

RH

On 12-Jun-07, at 06/12/07 10:05 AM, Nelson Santos wrote:

Hi Nima,



Thank you for your reply. So, exceptions should be reserved for problems
that are serious or fatal such as hardware failures? Which means I need to
decide which of my methods qualify for those cases, if any. But then
questions arise in my mind when I consider that the Cocoa frameworks throw
an exception if I try to access an element of NSArray outside the length of
the array. So, should I implement the same line of thinking whenever my
method's parameters are invalid? Probably not. I think the answer lies by
having a good balance between exceptions and returning nils/zeros from
methods that fail.




I agree with you that exceptions should be kept to a minimum.



Nelson

_______________________________________________

Cocoa-dev mailing list (email@hidden)

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


  • Follow-Ups:
    • Re: Error and Exception Handling: When to use
      • From: Nelson Santos <email@hidden>
References: 
 >RE: Error and Exception Handling: When to use (From: "Nelson Santos" <email@hidden>)

  • Prev by Date: Moderator EOT: Re: WWDC Leopard build
  • Next by Date: Re: error handling
  • Previous by thread: RE: Error and Exception Handling: When to use
  • Next by thread: Re: Error and Exception Handling: When to use
  • Index(es):
    • Date
    • Thread