{"id":15692,"date":"2016-08-29T12:56:58","date_gmt":"2016-08-29T16:56:58","guid":{"rendered":"http:\/\/mjtsai.com\/blog\/?p=15692"},"modified":"2016-08-29T12:56:58","modified_gmt":"2016-08-29T16:56:58","slug":"error-handling-compared","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2016\/08\/29\/error-handling-compared\/","title":{"rendered":"Error Handling Compared"},"content":{"rendered":"

Matt Gallagher<\/a>:<\/p>\n

\n

The Result<\/code> type is so useful that it was almost<\/em> included in the Swift standard library and even its rejection<\/em> reveals an interesting look at the philosophies underpinning Swift’s design.<\/p>\n

[…]<\/p>\n

Some implementations of Result<\/code> use a generic parameter for the error […] Frankly, until Swift supports structural sum types (and there is no guarantee that it ever will), this can potentially involve a lot of manual work propagating errors to communicate a small amount of additional type information that the interface user will promptly ignore by treating all errors identically (bail out on any error).<\/p>\n

[…]<\/p>\n

The effect<\/em> of Swift’s error handling over successive throws<\/code> statements is equivalent to the monadic flatMap<\/code> over multiple Result<\/code> generating functions but Swift avoids making abstract mathematical concepts like map<\/code> and flatMap<\/code> a required part of the core language and instead makes the code look<\/em> as though it is a simple, linear sequence of actions.<\/p>\n<\/blockquote>\n\n

Matt Gallagher<\/a>:<\/p>\n

\n

Given that all of the Swift compiler developers are themselves C++ developers, it is interesting that Swift has turned out almost, but not quite, entirely unlike C++. While Swift’s error handling offers potentially similar control flow to C++ exceptions, C++ exceptions provided the clearest example of what the Swift developers wanted to avoid with Swift.<\/p>\n

Swift would also rather solve problems with clear syntax rather than the numerous safe implementation rules required in C++. The defer<\/code> syntax used to manage cleanup at scope exit, including around thrown errors, is an example of language syntax avoiding the need for safe implementation rules like RAII<\/a>.<\/p>\n

[…]<\/p>\n

However, Haskell’s approach to error handling does have some limitations. Specifically, monadic handling makes it very easy to “bind” (>>=<\/code>) to get the “success” result and totally ignore what happens in an error case. Monadic handling encourages the ignoring of errors. If this code had omitted the catch<\/code> handling, the IO<\/code> monad would have propagated all the way to the output of the main<\/code> function.<\/p>\n

There’s also an almost total lack of signalling. Unless you look for the bind operator, do<\/code> notation or the catch<\/code>, return<\/code> or fail<\/code> functions, it’s difficult to know where IO<\/code> or other monads are involved. Haskell’s pervasive type inferencing is often a hindrance here: only one of these functions is required to actually specify a type signature.<\/p>\n

[…]<\/p>\n

While Swift has copied some of the syntactic elements of [Java] checked exceptions, Swift is very careful to avoid calling its errors “exceptions” since they are different in important ways. Most significantly, Swift’s errors are as performant as returning an error code and have no overlap with technology intended for fatal errors.<\/p>\n<\/blockquote>","protected":false},"excerpt":{"rendered":"

Matt Gallagher: The Result type is so useful that it was almost included in the Swift standard library and even its rejection reveals an interesting look at the philosophies underpinning Swift’s design. […] Some implementations of Result use a generic parameter for the error […] Frankly, until Swift supports structural sum types (and there is […]<\/p>\n","protected":false},"author":1,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"apple_news_api_created_at":"","apple_news_api_id":"","apple_news_api_modified_at":"","apple_news_api_revision":"","apple_news_api_share_url":"","apple_news_coverimage":0,"apple_news_coverimage_caption":"","apple_news_is_hidden":false,"apple_news_is_paid":false,"apple_news_is_preview":false,"apple_news_is_sponsored":false,"apple_news_maturity_rating":"","apple_news_metadata":"\"\"","apple_news_pullquote":"","apple_news_pullquote_position":"","apple_news_slug":"","apple_news_sections":"\"\"","apple_news_suppress_video_url":false,"apple_news_use_image_component":false,"footnotes":""},"categories":[4],"tags":[45,351,326,79,361,84,857,54,71,408,901],"class_list":["post-15692","post","type-post","status-publish","format-standard","hentry","category-programming-category","tag-c","tag-c-sharp","tag-c-plus-plus","tag-exceptions","tag-haskell","tag-java","tag-nserror","tag-objective-c","tag-programming","tag-rust-lang","tag-swift-programming-language"],"apple_news_notices":[],"_links":{"self":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/15692","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/comments?post=15692"}],"version-history":[{"count":1,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/15692\/revisions"}],"predecessor-version":[{"id":15693,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/posts\/15692\/revisions\/15693"}],"wp:attachment":[{"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/media?parent=15692"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/categories?post=15692"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/mjtsai.com\/blog\/wp-json\/wp\/v2\/tags?post=15692"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}