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.
  2. Just walked out the door at Zynga for the last time. New job starts Monday!
  3. @mdhughes Yes, that's pretty verbose and it required pulling the declaration of `in` to outside the try block.
  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?
  5. @mdhughes But you can't use @finally to clean up objects in the scope inside the @try, among other issues.
  6. @mdhughes That's only appropriate if you don't have to do cleanup in the local scope.
  7. @mdhughes Checking returns on every call is less verbose than @try/@catch on every call. And creation can be macro'd away.
  8. @statefullabs But in general I view the differences as exceptions are normally fatal, whereas errors should be handled.
  9. @statefullabs NSError forces you to acknowledge its existence. Exceptions are easy to ignore. And programmers are lazy.
  10. @mdhughes Things which should be handled locally are generally better suited to be written as NSErrors.
  11. @statefullabs I believe you should write your code such that you never have to handle exceptions except when calling untrusted code.
  12. @statefullabs Every single time you call -objectAtIndex:, do you wrap it in @try/@catch?
  13. @statefullabs My code needs to be able to handle errors, but it shouldn't be expected to handle exceptions. The programmer should.
  14. @statefullabs I view exceptions as indications of bad code (generally from violating the function contract), but errors are handleable.
  15. @statefullabs Probably because it litters their code with exception declarations that, in practice, are useless because they won't hit them.
  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
  17. @statefullabs That's not an IDE thing, that's a language thing, and it's something I've heard Java programmers complain about.
  18. @mdhughes NSException should be used for exceptional conditions. NSError is designed for non-exceptional error states. Different uses.
  19. @statefullabs I also think littering my code with @try/@catch is far more verbose and ugly than handling NSError values.
  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.