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 | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • 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" <drewmccormack...>
    To: <cocoa-dev...>
    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 | <cocoa-dev...>
    > 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 | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
  • On Tuesday, February 26, 2002, at 09:22 AM, Drew McCormack wrote:
    > 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?

    As far as the Cocoa APIs go: They do not use exceptions as a standard
    part of the API. Exceptions are reserved more for, well, exceptional
    situations that usually are not planned for, or for assertion failures
    where something goes wrong, usually as a result of programming or logic
    error (array index out of bounds, or similar parameter errors, assuming
    the recipient checks for those error conditions).

    Expected errors, including usual runtime failures or failures due to
    user errors, are reported via the standard API techniques, such as nil,
    BOOL, or error code returns, and in general apps do not need to catch
    exceptions as a result of Cocoa calls.  If an exception is raised, it
    ends up in the top level exception handler, which logs it; or you can
    deal with it by registering a top-level handler if you wish. By the time
    your app ships, various issues that were causing the exceptions have
    hopefully been addressed, so no shipping code should have to catch
    exceptions out of Cocoa calls.

    > 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.

    As Erik Buck points out exceptions can certainly come in handy within
    implementations of classes, and in fact, an expression parser is a great
    example of when to use exceptions. As far as the external API to your
    parser, you can choose to raise exceptions, in which case you should
    document the exceptions as API, or you can contain the exceptions and
    return error codes.  As mentioned above, Cocoa APIs prefer the latter.

    Ali
    _______________________________________________
    cocoa-dev mailing list | <cocoa-dev...>
    Help/Unsubscribe/Archives: http://www.lists.apple.com/mailman/listinfo/cocoa-dev
    Do not post admin requests to the list. They will be ignored.
previous month february 2002 next month
MTWTFSS
        1 2 3
4 5 6 7 8 9 10
11 12 13 14 15 16 17
18 19 20 21 22 23 24
25 26 27 28      
Go to today