{"id":9737,"date":"2025-04-15T17:45:00","date_gmt":"2025-04-15T14:45:00","guid":{"rendered":"https:\/\/handoli.com\/index.php\/2025\/04\/15\/using-swifts-defer-keyword-within-async-and-throwing-contexts\/"},"modified":"2025-04-15T17:45:00","modified_gmt":"2025-04-15T14:45:00","slug":"using-swifts-defer-keyword-within-async-and-throwing-contexts","status":"publish","type":"post","link":"https:\/\/handoli.com\/index.php\/2025\/04\/15\/using-swifts-defer-keyword-within-async-and-throwing-contexts\/","title":{"rendered":"Using Swift\u2019s defer keyword within async and throwing contexts"},"content":{"rendered":"

Swift\u2019s defer<\/code> keyword allows us to delay the execution of a given block of code until the current scope is exited. While that might initially not seem that<\/em> useful (after all, can\u2019t we simply write that code at the end of the scope instead?), it turns out that when writing modern Swift code, we\u2019re quite often dealing with multiple potential exit points within our functions and closures \u2014 especially when writing code that throws<\/code>, or when utilizing async\/await<\/code>.<\/p>\n

Let\u2019s take a look at the following SearchService<\/code> type\u2019s loadItems<\/code> method as an example. It uses a Database<\/code> API that requires a connection to be opened before any operations can be performed, and that connection then needs to be properly closed and cleaned up before new database requests can be accepted:<\/p>\n

actor<\/span> SearchService {\n    private let<\/span> database: Database<\/span>\n    ...\n\n    func<\/span> loadItems(maching searchString: String<\/span>) throws<\/span> -> [Item<\/span>] {\n        let<\/span> connection = database.connect<\/span>()\n\n        do<\/span> {\n            let<\/span> items: [Item<\/span>] = try<\/span> connection.runQuery<\/span>(.entries<\/span>(\n                matching: searchString\n            ))\n\n            connection.close<\/span>()\n            return<\/span> items\n        } catch<\/span> {\n            connection.close<\/span>()\n            throw<\/span> error\n        }\n    }\n}<\/code><\/pre>\n
\n
Note how we need to explicitly specify the type for our items<\/code> above, since the runQuery<\/code> method is generic, as it can return an array of any kind of database-compatible entry type that we\u2019re looking to retrieve.<\/p>\n<\/blockquote>\n
Because our code has two separate branches (one for when our runQuery<\/code> call succeeds, and one for when an error is thrown), we need to write separate calls to connection.close<\/code> within each branch. That might initially not seem like a big deal, but just like most code duplication, it increases the chance that we\u2019ll end up making a mistake, which could result in a quite major bug in this instance (as missing a close<\/code> call would leave the database unable to accept additional requests).<\/p>\n
One way to solve the above problem would be to ensure that our code only has a single branch of execution. In the case of the above loadItems<\/code> method, that could be done by using the closure-based Result<\/code> initializer included in the standard library, which converts a throwing closure into a result, which can then be unwrapped once we\u2019ve closed our database connection \u2014 like this:<\/p>\n
actor<\/span> SearchService {\n    private let<\/span> database: Database<\/span>\n    ...\n\n    func<\/span> loadItems(maching searchString: String<\/span>) throws<\/span> -> [Item<\/span>] {\n        let<\/span> connection = database.connect<\/span>()\n\n        let<\/span> result = Result<\/span><[Item<\/span>], Error<\/span>> {\n            try<\/span> connection.runQuery<\/span>(.entries<\/span>(matching: searchString))\n        }\n\n        connection.close<\/span>()\n        return<\/span> try<\/span> result.get<\/span>()\n    }\n}<\/code><\/pre>\n
While that\u2019s certainly an improvement \u2014 let\u2019s now take a look at how defer<\/code> lets us solve the problem in an arguably much more elegant way, since it\u2019ll let us define the closing of our database connection right next to where the connection is opened:<\/p>\n
actor<\/span> SearchService {\n    private let<\/span> database: Database<\/span>\n    ...\n\n    func<\/span> loadItems(maching searchString: String<\/span>) throws<\/span> -> [Item<\/span>] {\n        let<\/span> connection = database.connect<\/span>()\n        defer<\/span> { connection.close<\/span>() }\n\n        return try<\/span> connection.runQuery<\/span>(.entries<\/span>(matching: searchString))\n    }\n}<\/code><\/pre>\n
Nice! Not only are the calls to connect<\/code> and close<\/code> now right next to each other (which arguably makes it easier to reason about those two calls as a pair), but because we can now directly return the result of our runQuery<\/code> call, we no longer have to manually specify any type information \u2014 the compiler can now automatically infer the return type of that call for us.<\/p>\n
Using defer<\/code> does have somewhat of a downside, though, in that it sort of breaks the traditional control flow model that structured programming tends to follow \u2014 where instructions are always executed from top to bottom. Within our current loadItems<\/code> implementation, for example, we now have three expressions:<\/p>\n