Profile_bird

Hey there! eridius is using Twitter.

Twitter is a free service that lets you keep in touch with people through the exchange of quick, frequent answers to one simple question: What are you doing? Join today to start receiving eridius's tweets.

Already using Twitter
from your phone? Click here.

eridius

  1. @Skroob I'm going to work for the same startup that @annekate is working for. about 20 hours ago from Tweetie in reply to Skroob
  2. Just walked out the door at Zynga for the last time. New job starts Monday! about 23 hours ago from Tweetie
  3. @mdhughes Yes, that's pretty verbose and it required pulling the declaration of `in` to outside the try block. 6:48 PM Nov 12th from Tweetie in reply to mdhughes
  4. @mdhughes Also if you're covering multiple calls with one @try block, you don't know how far you got in @finally so what do you clean up? 6:42 PM Nov 12th from Tweetie in reply to mdhughes
  5. @mdhughes But you can't use @finally to clean up objects in the scope inside the @try, among other issues. 6:42 PM Nov 12th from Tweetie in reply to mdhughes
  6. @mdhughes That's only appropriate if you don't have to do cleanup in the local scope. 6:35 PM Nov 12th from Tweetie in reply to mdhughes
  7. @mdhughes Checking returns on every call is less verbose than @try/@catch on every call. And creation can be macro'd away. 6:30 PM Nov 12th from Tweetie in reply to mdhughes
  8. @statefullabs But in general I view the differences as exceptions are normally fatal, whereas errors should be handled. 6:22 PM Nov 12th from Tweetie in reply to statefullabs
  9. @statefullabs NSError forces you to acknowledge its existence. Exceptions are easy to ignore. And programmers are lazy. 6:20 PM Nov 12th from Tweetie in reply to statefullabs
  10. @mdhughes Things which should be handled locally are generally better suited to be written as NSErrors. 6:16 PM Nov 12th from Tweetie in reply to mdhughes
  11. @statefullabs I believe you should write your code such that you never have to handle exceptions except when calling untrusted code. 6:16 PM Nov 12th from Tweetie in reply to statefullabs
  12. @statefullabs Every single time you call -objectAtIndex:, do you wrap it in @try/@catch? 6:05 PM Nov 12th from Tweetie in reply to statefullabs
  13. @statefullabs My code needs to be able to handle errors, but it shouldn't be expected to handle exceptions. The programmer should. 6:00 PM Nov 12th from Tweetie in reply to statefullabs
  14. @statefullabs I view exceptions as indications of bad code (generally from violating the function contract), but errors are handleable. 6:00 PM Nov 12th from Tweetie in reply to statefullabs
  15. @statefullabs Probably because it litters their code with exception declarations that, in practice, are useless because they won't hit them. 5:59 PM Nov 12th from Tweetie in reply to statefullabs
  16. @pilky Yeah, I actually like that I don't have to handle exceptions - in most cases I have no idea how to respond to them, so I'd rather die 5:57 PM Nov 12th from Tweetie in reply to pilky
  17. @statefullabs That's not an IDE thing, that's a language thing, and it's something I've heard Java programmers complain about. 5:57 PM Nov 12th from Tweetie in reply to statefullabs
  18. @mdhughes NSException should be used for exceptional conditions. NSError is designed for non-exceptional error states. Different uses. 5:57 PM Nov 12th from Tweetie in reply to mdhughes
  19. @statefullabs I also think littering my code with @try/@catch is far more verbose and ugly than handling NSError values. 5:56 PM Nov 12th from Tweetie in reply to statefullabs
  20. @mdhughes The problem with exceptions is you aren't forced to handle them, so most people simply don't. This is a very bad practice. 5:53 PM Nov 12th from Tweetie in reply to mdhughes