Re: Error and Exception Handling: When to use
Re: Error and Exception Handling: When to use
- Subject: Re: Error and Exception Handling: When to use
- From: Nelson Santos <email@hidden>
- Date: Tue, 12 Jun 2007 13:14:55 -0400
Hi Ryan,
Thanks for your reply. I think I tend to agree more with your view
on exceptions. I don't have much experience working with exceptions
myself, but so far it makes sense to me to throw exceptions whenever
a program encounters something it didn't expect (such as an argument
with an unexpected value, or a method returns an unexpected value).
However, I think that Kirk's point of a method returning zero or nil
has some merit as well (especially when dealing with creation of
objects).
See my previous post which contains a snip of the Apple Error
Handling Programming Guide which supports much of what you said and
which affirms your NSApp suspicion.
Thanks again!
Nelson
On 12-Jun-07, at 11:48 AM, Ryan Homer wrote:
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
_______________________________________________
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