Codingexplorer.com Website Review

Ideally, errors should never occur.  File we need should always be available and networks should always be present and reliable.  Unfortunately this reality is not ideal and we have to deal with the consequences.  Thankfully the Swift team included a great way to handle these deviations from the ideal in Swift 2.  Swift Error Handling lets us quickly and easily warn the compiler whether a function can throw an error, actually throw it, and handle it in whatever way seems appropriate. In many types of apps, you have to access files.  They can be in your app bundle, on the file system, or even somewhere on the web.  You need to have someway to refer to where they are in your code.  On Apple platforms, you basically have 2 choices, as a String or aURL. Given the address bar right above you, or any use of a terminal, a Swift String would be a very understandable choice, I mean, that’s all that text is in the address bar, right?  Many of the older APIs in the Cocoa and Cocoa Touch SDKs take URLs and Strings (referred to as a “path” in those APIs usually), but things are moving more and more towards just using URL objects everywhere.  URL objects have many advantages over String paths, most notably that you can access different parts of the URL from properties, instead of having to write your own code to parse those components from the path String. Stay tuned as we learn a thing or two about creating and using URL objects in your Swift app. In the age of watchOS 1, the watchKit extension was on the paired iOS device, making sharing data between it and the main iOS app easy.  For the simplest of data, like preferences, we could just use NSUserDefaults with App Groups functionality.  We still should use that when sharing data between other extensions that still remain on the phone, like today view extensions, but not for watchOS apps Luckily, Apple gave us a new API to use, that is significantly more robust than piggy-backing on App Groups, Watch Connectivity.  Watch