{"id":25193,"date":"2019-05-08T19:17:44","date_gmt":"2019-05-08T23:17:44","guid":{"rendered":"https:\/\/mjtsai.com\/blog\/?p=25193"},"modified":"2019-05-08T19:18:17","modified_gmt":"2019-05-08T23:18:17","slug":"optional-throws-result-and-asyncawait","status":"publish","type":"post","link":"https:\/\/mjtsai.com\/blog\/2019\/05\/08\/optional-throws-result-and-asyncawait\/","title":{"rendered":"Optional, throws, Result, and async\/await"},"content":{"rendered":"

Joshua Emmons<\/a>:<\/p>\n

\n

Ah ha! So we see that the Result<\/code> type can serve as a concrete reification<\/a> of Swift’s abstract idea of “that thing that’s returned when a function is marked as throws<\/code>.”<\/em> And as such, we can use it to deal with asynchronous operations that require concrete types for parameters passed to their completion handlers.<\/p>

[…]<\/p>

Thankfully, we can clean this up by taking advantage of the fact that, like Optional<\/code>, Result<\/code> implements flatMap<\/code><\/a>. Specifically, flatMap<\/code> on a Result<\/code> will, in the case of .success<\/code>, apply the given transform to the associated value and return the newly produced Result<\/code>. In the case of a .failure<\/code>, however, flatMap<\/code> simply passes the .failure<\/code> and its associated error along without modification.<\/p>

[…]<\/p>

In the near term, we just have to lump it.\n It’s better than the other alternatives native to the language,\n and chaining asynchronous calls isn’t as common as for synchronous calls.<\/p>\n

But in the future, just as Swift used do\/catch<\/code> syntax to define away Result<\/code> nesting problems in synchronous error handling, there are many proposals being considered to do the same for asynchronous errors (and asynchronous processing, generally).<\/p>\n<\/blockquote>\n\n

See also: Localized​Error, Recoverable​Error, Custom​NSError<\/a>.<\/p>\n\n

Previously:<\/p>\n