Todd Ditchendorf

@iTod I knew about it, but when there are multiple things to clean up, try/finally is so awkward that people use goto and multiple labels.

@iTod @mjtsai commented on your gist... but fundamentally, why add runtime overhead for no real advantage? There are disadvantages.

@owensd for goto versus try/finally I was commenting on @mjtsai's awkwardness claim only.

@iTod @owensd I'm not a fan of the extra lines at the top to declare the variables, the extra indentation, or repeating the return value.

@iTod it's not that you cannot do it, it's that the amount of code needed to do it correctly is much greater and more error prone.

@iTod also, try/finally only applies to exceptions, which is explicitly what errors are in Swift. You need to use NSError in ObjC.

@iTod though honestly, I'd flag code as bad code. Why are using exception handling code for non-exception handling circumstances?

@owensd Strongly disagree, and this is my point. try/finally has important and perfectly reasonable applications for non-exceptional code.

@iTod using try/finally outside of exceptions is confusing; defer gets you what you want without the cost or overloaded usage.

@owensd 1) I disagree. This is somewhat common in Java land. 2) One could make an opposite "economy of constructs" argument for try/finally

@iTod NS_VALID_UNTIL_END_OF_SCOPE an object that runs a block on dealloc is another way. Just make sure nothing else retains the object.

@iTod But… I thought it had to do with when it executes. Doesn’t defer wait until after the current scope is exited? Or… Uh… Stuff?