{"id":50,"date":"2016-03-03T10:59:34","date_gmt":"2016-03-03T16:59:34","guid":{"rendered":"https:\/\/chibicode.org\/?p=50"},"modified":"2016-03-03T11:00:47","modified_gmt":"2016-03-03T17:00:47","slug":"optional-return-vs-throws-pick-one","status":"publish","type":"post","link":"https:\/\/chibicode.org\/?p=50","title":{"rendered":"Optional Return vs throws: Pick One"},"content":{"rendered":"<p>Swift 2 provides a number of ways to indicate a problem in a method that returns a value, but the two most common are optional return values and throwing errors. Which you choose comes down to your requirements for a particular function, which I will discuss below. But if you take nothing else away from this post, take this: <strong>Don&#8217;t use both!<\/strong><\/p>\n<p>That is not to say you can&#8217;t use both approaches in your app, just don&#8217;t use them both in a single function.<\/p>\n<h2>Optional Returns<\/h2>\n<p><strong>Pros:<\/strong> Simple to write, simple to handle<br \/>\n<strong>Cons:<\/strong> Uninformative<\/p>\n<p>The most common method for indicating failure in a function that returns a value is to make that value optional and return nil when a problem occurs that prevents the successful completion of the function. This has been available since Swift 1.0 and the language has a lot of syntactical features to allow you to efficiently detect and handle nil responses.<\/p>\n<p>Optional returns should be your first choice when all you care about is whether or not a value was returned from a function, not <em>why<\/em> the function may have failed.<\/p>\n<h3>Example:<\/h3>\n<p>[gist https:\/\/gist.github.com\/JoshuaSullivan\/c0dc873c7d48cee1c1c4 file=&#8221;OptionalReturn.swift&#8221;]<\/p>\n<h2>Throwing Functions<\/h2>\n<p><strong>Pros:<\/strong> Informative errors allow robust recovery options, non-optional return values<br \/>\n<strong>Cons:<\/strong> More verbose syntax to handle errors (if you don&#8217;t just ignore them with <code>try?<\/code>)<\/p>\n<p>Swift 2 introduced a robust error handling mechanism to Swift. Functions marked with <code>throws<\/code> can throw errors which calling objects must explicitly handle or ignore. Having a well-defined set of errors allows calling objects to implement an intelligent recovery plan in the event of a failure, such as correcting erroneous input and trying again. The down-side is that writing error handling code gets verbose, with the do-catch blocks.<\/p>\n<h3>Example:<\/h3>\n<p>[gist https:\/\/gist.github.com\/JoshuaSullivan\/c0dc873c7d48cee1c1c4 file=&#8221;ThrowingFunction.swift&#8221;]<\/p>\n<h2>Combining Optional Returns and Errors<\/h2>\n<p><strong>Don&#8217;t!<\/strong> If you don&#8217;t want to bother with errors, then your method should just return an optional value. If you do go to the effort of adding errors, let them communicate problems and guarantee a non-nil return value from your function. If the calling object doesn&#8217;t want to handle the errors, it can simply invoke your function with <code>try?<\/code> and treat the return value as optional. If the calling function does handle the errors, allow it to forgo the extra steps of handling optional return values.<\/p>\n","protected":false},"excerpt":{"rendered":"<p>Swift 2 provides a number of ways to indicate a problem in a method that returns a value, but the two most common are optional return values and throwing errors. Which you choose comes down to your requirements for a particular function, which I will discuss below. But if you take nothing else away from &hellip; <a href=\"https:\/\/chibicode.org\/?p=50\" class=\"more-link\">Continue reading<span class=\"screen-reader-text\"> &#8220;Optional Return vs throws: Pick One&#8221;<\/span><\/a><\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"closed","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[5],"tags":[19,18,6,20],"class_list":["post-50","post","type-post","status-publish","format-standard","hentry","category-code","tag-errors","tag-optionals","tag-swift","tag-throw"],"_links":{"self":[{"href":"https:\/\/chibicode.org\/index.php?rest_route=\/wp\/v2\/posts\/50","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/chibicode.org\/index.php?rest_route=\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/chibicode.org\/index.php?rest_route=\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/chibicode.org\/index.php?rest_route=\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/chibicode.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcomments&post=50"}],"version-history":[{"count":5,"href":"https:\/\/chibicode.org\/index.php?rest_route=\/wp\/v2\/posts\/50\/revisions"}],"predecessor-version":[{"id":55,"href":"https:\/\/chibicode.org\/index.php?rest_route=\/wp\/v2\/posts\/50\/revisions\/55"}],"wp:attachment":[{"href":"https:\/\/chibicode.org\/index.php?rest_route=%2Fwp%2Fv2%2Fmedia&parent=50"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/chibicode.org\/index.php?rest_route=%2Fwp%2Fv2%2Fcategories&post=50"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/chibicode.org\/index.php?rest_route=%2Fwp%2Fv2%2Ftags&post=50"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}