This I think is the first time that I have seen someone suggest multiple return points from a function.
Standard thoughts tend to suggest only a single point of exit from a method greatly improves code readability and complexity. Wil Shipley in an article on his blog called Code Insults Mark 1 calls it a bogus notion.
I can't imagine what justification anyone would have for only wanting a single point of return from a method/function/whatever. There may be some pure math or logic or whatever theory behind this, but I think basically it's a completely bogus notion. It's a zillion times easier to understand a method (function, whatever) in terms of "Do something. Am I still on the right course? No? Then bail. Do something else. Am I still on the right course? No? The bail... [etc]" than it is to do all that nesting crap. I've never heard anyone espouse that single-exit is better thing, except possibly back in the days of Modula-2. Remember Nikolas Wirth anyone? No? You know why? BECAUSE HE WAS WRONG. He was a total "purity of code" guy, on of the people behind the no-goto movement, one of the architects of the strongly-typed language movement, etc. For a couple years we all bought into it. Then we noticed that, still, all the interesting software was being written in C. The notion that a function in a programming language should be like a function in math has been disproven by the history of real programming. We've got flow control. We should use it. One return point... yeesh. Can anyone top that for bizarre coding edicts? Anyone not allowed to use capital letters? Anyone not allowed to type the 'e' key in their programs?
From a post on Ars Technica
If you want to become a hard-core Mac developer, I'd highly recommend learning a little bit about each technology underlying Mac OS X:
1) Basic BSD Unix (filehandles, processes, permissions)
2) Basic Mach (ports, threads, tasks, messages)
3) Core Foundation (CFRunLoop, CFString, CFArray, CFNotificationCenter)
Once you've written programs to take advantage of each of these, then you'll really be able to understand Cocoa. If you don't understand these, then a lot of Cocoa will seem like magic to you.. and as a professional programmer, your job is to untangle and solve mysteries.
Avoid Carbon, but be very aware of the side effects of using it. Many Carbon APIs do sneaky things like registering callbacks without telling you, affecting the rest of your program.