4 ms·

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

by halayli 11y ago

McElroy 11y ago
While try/catch is what is exposed to us as developers, the underlying implementation could very well be advanced.
pilif 11y ago
Advanced compared to what was there in previous releases (basically an Error out parameter that you had to check on your own)
Joky 11y ago
Advanced != Exclusive/Innovative/... That said, the spec here is a bit different than C++ exception I believe.
- Someone 11y ago
  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)
  - 72deluxe 11y ago
    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?
    - lobster_johnson 11y ago
      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.
pjmlp 11y ago
Some language designers feel it is so advanced that developers working on coal mines should not be allowed to use it.
vog 11y ago
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.
- halayli 11y ago
  exactly my point. It's marketing mumbo jumbo.
  - vacri 11y ago
    The /etc/bus: http://thedailywtf.com/articles/The__0x2f_etc_0x2f_bus http://thedailywtf.com/articles/The__0x2f_etc_0x2f_bus
hhghd 11y ago
Incredibly disappointing. Should be a library provided Result type (or hell, even an anointed type like Optional, anything but exceptions).
Dewie3 11y ago
They also described Swift's `Optional` type as innovative. https://developer.apple.com/swift/ https://developer.apple.com/swift/
smtddr 11y ago
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.
- hundchenkatze 11y ago
  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.
- cellularmitosis 11y ago
  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).
  - e28eta 11y ago
    "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#exceptions http://clang.llvm.org/docs/AutomaticReferenceCounting.html#e...
    - sjwright 11y ago

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

by halayli 11y ago

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

McElroy 11y ago

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

pilif 11y ago

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

Joky 11y ago

Advanced != Exclusive/Innovative/... That said, the spec here is a bit different than C++ exception I believe.

Someone 11y ago
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)
- 72deluxe 11y ago
  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?
  - lobster_johnson 11y ago
    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.

pjmlp 11y ago

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

vog 11y ago

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.

halayli 11y ago
exactly my point. It's marketing mumbo jumbo.
- vacri 11y ago
  The /etc/bus: http://thedailywtf.com/articles/The__0x2f_etc_0x2f_bus http://thedailywtf.com/articles/The__0x2f_etc_0x2f_bus

hhghd 11y ago

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

Dewie3 11y ago

They also described Swift's `Optional` type as innovative. https://developer.apple.com/swift/ https://developer.apple.com/swift/

smtddr 11y ago

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.

hundchenkatze 11y ago
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.
cellularmitosis 11y ago
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).
- e28eta 11y ago
  "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#exceptions http://clang.llvm.org/docs/AutomaticReferenceCounting.html#e...
  - sjwright 11y ago