Hacker News Reader

Comment by halayli | Hacker News Reader

"Advanced error handling model using try / catch / throw that feels natural in Swift."

yeah try/catch is very advanced.

Not sure why this is downvoted. I find it totally appropriate to criticize marketing speak that is masked as technical description.

Regarding Apple, I find it inappropriate (and dishonest) to use the word "advanced", when it is just catching up with a commodity feature. Exceptions are provided by almost every other modern programming language in the world.

exactly my point. It's marketing mumbo jumbo.

The /etc/bus: http://thedailywtf.com/articles/The__0x2f_etc_0x2f_bus

Advanced compared to what was there in previous releases (basically an Error out parameter that you had to check on your own)

Advanced != Exclusive/Innovative/...

That said, the spec here is a bit different than C++ exception I believe.

Agreed. Also, it does look different aka innovative to me:

    func loadData() throws { }

    func test() {
      do {
        try loadData()
      } catch {
        print(error)
      }
    }

I guess that you have to prefix any statement that might throw with 'try', and cannot prefix other statements with it.

If so, their motto really seems to be 'explicit over implicit'. I'm not sure that is an improvement, but I'm not sure that it is bad, either, provided that the refactoring tools work fine (for example when one removes that "throws" from the definition of loadData)

Doesn't that mean typing try a million times instead of putting potentially throwable calls inside one try block and a bunch of different catch handlers?

I wonder why they insist on that. Perhaps it is easier to parse?

I suspect it's useful to visually signal that the call can fail, and make it obvious what's happening; after all, the "throws" annotation is at the target site, not on the caller end.

You need to prefix anything that throws with a "try":

    func mightThrow() throws {
      try mightAlsoThrow();
    }

Other than that, it looks exactly like C++ exceptions: Propagation happens along the chain of functions marked as "throws", until a "catch" handler intercepts it.

"try" is an expression, by the way, so you can do things like:

    let line = try file.readline()

There's also a "try!" statement that throws a runtime exception if the inner statement throws.

Incredibly disappointing. Should be a library provided Result type (or hell, even an anointed type like Optional, anything but exceptions).

You have to understand though, Swift is like a really nice wrapper around Objective-C. Imagine adding try/catch to C programming language? I know python & java and all of today's relevant high-level languages have it since forever, but implementing that in something that wasn't designed for it from the start is a big task. I'm by no stretch of the imagination an Apple fanatic but as a person who is about to send out their first mobile app, which happens to be for iOS, I acknowledge the difficulty of adding try/catch to Swift... and by extension any Obj-C or plain C used in that same XCode project.

While Swift was designed to interface well with Objective-C and runs on the Objective-C runtime, it is not a wrapper around Objective-C. It was written from the ground up, started by Chris Lattner at Apple.

Obj-C already had try / catch, it just wasn't considered idiomatic to the platform. Amazon caught a bunch of flak when they wrote an Obj-C interface to AWS and all of the error handling was try/catch instead of NSError (probably, they just line-for-line transliterated their Java interface).

"The standard Cocoa convention is that exceptions signal programmer error and are not intended to be recovered from. Making code exceptions-safe by default would impose severe runtime and code size penalties on code that typically does not actually care about exceptions safety. Therefore, ARC-generated code leaks by default on exceptions, which is just fine if the process is going to be immediately terminated anyway. Programs which do care about recovering from exceptions should enable the option."

http://clang.llvm.org/docs/AutomaticReferenceCounting.html#e...

ARC was short lived and is deprecated.

Am I missing something? ARC is the default when you start any ObjC-based Xcode project. It's not deprecated.

While try/catch is what is exposed to us as developers, the underlying implementation could very well be advanced.

Some language designers feel it is so advanced that developers working on coal mines should not be allowed to use it.

They also described Swift's `Optional` type as innovative.

https://developer.apple.com/swift/

Reply on news.ycombinator.com