6 ms·

I bought a whole book to tell me the same information as in the PDF. I like this PDF better. The book was odd, though: Not one mention of exceptions or error h

by jorgem 18y ago

I bought a whole book to tell me the same information as in the PDF. I like this PDF better. The book was odd, though: Not one mention of exceptions or error handling in a whole book. Sigh

silencio 18y ago
Out of curiosity, which book was this? And on a sidenote, Apple has some extensive documentation on that available in the docs.
- ivanzhao 18y ago
  not really sure. I found it through an arbitrary google search.
  - silencio 18y ago
    ah, sorry if it wasn't clear, i meant to ask jorgem about the book that didn't mention exceptions :) although, i have seen this particular pdf floating around before, and i keep forgetting to bookmark it and this time i did, so thank you :)
    - jorgem 18y ago
      Learn Objective–C on the Mac (Learn Series)
ankhmoop 18y ago
I reviewed the exception section, and was surprised to see no mention of this tidbit from Apple's developer documentation: "You should reserve the use of exceptions for programming or unexpected runtime errors such as out-of-bounds collection access, attempts to mutate immutable objects, sending an invalid message, and losing the connection to the window server. You usually take care of these sorts of errors with exceptions when an application is being created rather than at runtime." The reason for this is fairly straight-forward -- very little Objective-C code is exception-safe, it's relatively difficult to make it exception safe, and blindly traversing the call stack to the nearest exception handler will result in leaked resources and associated failures. The correct way to handle errors in Objective-C is with NSError return values, which properly supports (among other things) reporting localized error messages and possible solutions to the user using standard UI, and optionally taking action on that solution using a recovery handler. The Apple documentation on these subjects is quite comprehensive. (edit) I should also mention that as of Objective-C 2.0, the language (Obj-C) and Apple's Foundation library are effectively linked. The compiler contains numerous direct dependencies on the Foundation library for the purpose of implementing properties, 'fast' enumeration, etc. While it used to be possible to claim that the languages and library were distinct (nothing prevented you from using a base class library other than Foundation), this is no longer necessarily the case. Any use of raw Objective-C requires the existence of Foundation-compatible protocol implementations. Thus, any modern discussion of Objective-C 2.0 error handling is arguably lacking without mention of Foundation's facilities. Likewise, discussion of Objective-C 1.0 error handling would have extended beyond the domain of Objective-C were it to include mention of the Foundation library's facilities.

by jorgem 18y ago

I bought a whole book to tell me the same information as in the PDF. I like this PDF better. The book was odd, though: Not one mention of exceptions or error handling in a whole book. Sigh

silencio 18y ago

Out of curiosity, which book was this? And on a sidenote, Apple has some extensive documentation on that available in the docs.

ivanzhao 18y ago
not really sure. I found it through an arbitrary google search.
- silencio 18y ago
  ah, sorry if it wasn't clear, i meant to ask jorgem about the book that didn't mention exceptions :) although, i have seen this particular pdf floating around before, and i keep forgetting to bookmark it and this time i did, so thank you :)
  - jorgem 18y ago
    Learn Objective–C on the Mac (Learn Series)

ankhmoop 18y ago

I reviewed the exception section, and was surprised to see no mention of this tidbit from Apple's developer documentation: "You should reserve the use of exceptions for programming or unexpected runtime errors such as out-of-bounds collection access, attempts to mutate immutable objects, sending an invalid message, and losing the connection to the window server. You usually take care of these sorts of errors with exceptions when an application is being created rather than at runtime." The reason for this is fairly straight-forward -- very little Objective-C code is exception-safe, it's relatively difficult to make it exception safe, and blindly traversing the call stack to the nearest exception handler will result in leaked resources and associated failures. The correct way to handle errors in Objective-C is with NSError return values, which properly supports (among other things) reporting localized error messages and possible solutions to the user using standard UI, and optionally taking action on that solution using a recovery handler. The Apple documentation on these subjects is quite comprehensive. (edit) I should also mention that as of Objective-C 2.0, the language (Obj-C) and Apple's Foundation library are effectively linked. The compiler contains numerous direct dependencies on the Foundation library for the purpose of implementing properties, 'fast' enumeration, etc. While it used to be possible to claim that the languages and library were distinct (nothing prevented you from using a base class library other than Foundation), this is no longer necessarily the case. Any use of raw Objective-C requires the existence of Foundation-compatible protocol implementations. Thus, any modern discussion of Objective-C 2.0 error handling is arguably lacking without mention of Foundation's facilities. Likewise, discussion of Objective-C 1.0 error handling would have extended beyond the domain of Objective-C were it to include mention of the Foundation library's facilities.