New Objective-C Tutorial

Discussion in 'Wasteland' started by ryanhodson, Jan 31, 2013.

Thread Status:
Not open for further replies.
  1. ryanhodson macrumors newbie

    Jan 31, 2013
    Hey iOS devs!

    I just published a comprehensive Objective-C tutorial at:

    I thought it would be a very useful reference for the beginning developers hanging around the MacRumors forums.

    If any experienced programmers have the time to read through it (or part of it) over the next few weeks, feedback would be greatly appreciated.

  2. ArtOfWarfare macrumors 604


    Nov 26, 2007
    I read the section on Errors and Exceptions.

    I have to confess, I've never use any error/exceptions in Obj-C... and the excessive use of them is what makes me call C++ and Java ugly languages.

    Is there any situation in which it'd be appropriate to actually @throw an exception?
  3. ryanhodson thread starter macrumors newbie

    Jan 31, 2013
    @throw is useful if you're writing a public library for others to use, since it lets the programmer know when they passed an invalid argument, when an internal state has been corrupted, or when something else has gone fatally wrong and the app needs to crash.

    In application code, you should pretty much always use NSError instead of NSException.

    I'll be sure to edit the tutorial to make that clearer. Thanks!
  4. ianray macrumors 6502

    Jun 22, 2010
    Just to follow up on exceptions -- I generally look to the built-in frameworks and APIs to get a sense of what idiomatic iOS code should look like.

    In that sense using exceptions to throw errors across a library boundary looks very unusual.

    Your tutorial looks very detailed; I will have a proper look later :)
  5. ryanhodson thread starter macrumors newbie

    Jan 31, 2013
    I was actually thinking of it from that perspective. For example, when you try to access an NSArray element that doesn't exist, it throws an exception so you know you did something bad.

    To clarify, you shouldn't ever use @throw to communicate an *error* across a library boundary, but it would be appropriate for a library to throw an *exception* for the programmer to catch.

    Correct me if I'm wrong, and let me know if you have any other feedback. Thanks!
Thread Status:
Not open for further replies.

Share This Page