Re: Best practice for exceptions
Re: Best practice for exceptions
- Subject: Re: Best practice for exceptions
- From: "Erik M. Buck" <email@hidden>
- Date: Tue, 26 Feb 2002 13:14:31 -0600
Here are two rules of thumb that I use regardless of language:
When to use Assert:
Use assert to test pre-conditions and post-conditions and to verify the
returned values from function and method calls, but ONLY use assert to
verify expected values. Assert is a sanity check. If you would write a
comment like "This should never happen" or "We are not in Kansas anymore
Toto" then Assert is appropriate. In other words, if error results are
expected in some situations, don't use Assert to test for an error result.
Assert is only for unexpected values and if an error is sometimes expected
then it is not unexpected. Assert failures raise exceptions. The rules for
exceptions are therefore related.
When to use Exceptions:
Exceptions have two main uses. They replace "goto" in some cases and they
act as handlers for serious errors that can not be handled locally. In the
first case, exceptions are a convenience for programmers. In the second
case, exceptions are the technique of last resort.
In the "goto" usage, any exceptions raised within a function or method MUST
be handled within the same function or method or within a calling function
or method within the same class. The simplest for of the rule is that
programmers who use the class should never have to handle "goto" style
exceptions raised within the implementation of the class. Any "goto" style
exceptions are raise purely for the convenience of the class implementor and
never for the "inconvenience" of the classes users. "Goto" style exceptions
are NOT part of a class's public interface. There may be examples of this
type of exception in Cocoa, but we don't know because they are correctly
hidden in the implementations of classes.
In the "last resort serious error" case, exceptions ARE part of a class's
public interface. All exceptions that can ever be raised by a method/class
but not handled internally by the method/class MUST be documented. This type
of exception is used similarly to the Assert. These exceptions should only
be raised if something unexpected happened. Normal/expected error results
should NOT cause and exception to be raised. Examples of valid "last resort
serious error" exception in Cocoa are the "Attempt to send a message to a
deallocated object" and "Object does not respond to selector".
In the case of a parser that can be expected to encounter user input errors,
don't use an exception to indicate the error. Use a notification instead.
Post a notification of the error detected and then call and "abort" method
or try to continue parsing. An interested observer can register for the
"syntax error" exception and use any associated user data to report the
error or change the state of the parser or whatever.
----- Original Message -----
From: "Drew McCormack" <email@hidden>
To: <email@hidden>
Sent: Tuesday, February 26, 2002 11:22 AM
Subject: Best practice for exceptions
>
I was wondering if someone with plenty of experience would like to
>
explain how they utilize exceptions in their cocoa apps. I can never
>
figure out when I should throw an exception, and when I should, for
>
example, set a flag and put details of the failure in a string to return
>
to the caller. Is there a general consensus on this?
>
>
For example, I am writing an expression parser. If the parser comes
>
across a syntax error in the expression, which was entered by the user,
>
should I throw an exception, or simply return an error code to the
>
caller, with a message to display to the user. It's not an exception in
>
the sense that something completely unexpected has happened, since user
>
error is to be expected. On the other hand, exceptions seem to be more
>
elegant than setting a failure flag and adding an extra 'message'
>
argument to function, like in the old days.
>
>
Drew
>
... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ... ...
>
... ... ... ... ... ... ... ...
>
Dr. Drew McCormack
>
Trade Strategist (www.trade-strategist.com)
>
Trading simulation software for Mac OS X
>
_______________________________________________
>
cocoa-dev mailing list | email@hidden
>
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
>
Do not post admin requests to the list. They will be ignored.
_______________________________________________
cocoa-dev mailing list | email@hidden
Help/Unsubscribe/Archives:
http://www.lists.apple.com/mailman/listinfo/cocoa-dev
Do not post admin requests to the list. They will be ignored.