|
1 | 1 | +++ |
2 | | -date = 2025-12-07T11:11:24+01:00 |
3 | | -draft = true |
4 | | -title = "" |
5 | | -description = "altai 1.0.0 is available" |
| 2 | +date = 2025-12-06T11:11:24+01:00 |
| 3 | +draft = false |
| 4 | +title = "altai: elevating typed throws in Swift" |
| 5 | +description = "altai: elevating typed throws in Swift" |
6 | 6 | slug = "altai-released" |
7 | 7 | authors = ["Calogero Sanfilippo"] |
8 | 8 | tags = ["altai", "swift"] |
9 | 9 | +++ |
| 10 | + |
| 11 | +[Swift 6](https://www.swift.org/blog/announcing-swift-6/) introduced *typed throws*, a powerful enhancement that allows developers to declare the specific error types a function may throw. While this feature improves clarity and safety, it also introduces challenges, particularly when dealing with nested or heterogeneous error sources. |
| 12 | + |
| 13 | +**altai**, a lightweight Swift package, addresses these pain points by offering a clean, idiomatic way to uplift and unify errors without verbose boilerplate. |
| 14 | + |
| 15 | +## The problem with typed throws |
| 16 | + |
| 17 | +Typed throws enable functions to specify error types directly in their signatures: |
| 18 | + |
| 19 | +```swift |
| 20 | +enum CustomError: Error { |
| 21 | + case oddNumber |
| 22 | + case decodingError |
| 23 | +} |
| 24 | + |
| 25 | +func throwingIfOdd(_ number: String) throws(CustomError) -> Int { |
| 26 | + |
| 27 | + do { |
| 28 | + let number = try JSONDecoder().decode(Int.self, from: number.data(using: .utf8)!) |
| 29 | + |
| 30 | + guard isEven(number) else { |
| 31 | + throw CustomError.oddNumber |
| 32 | + } |
| 33 | + |
| 34 | + return number |
| 35 | + } catch { |
| 36 | + if let customError = error as? CustomError { |
| 37 | + throw customError |
| 38 | + } else { |
| 39 | + throw .decodingError |
| 40 | + } |
| 41 | + } |
| 42 | +} |
| 43 | +``` |
| 44 | + |
| 45 | +This improves compiler awareness and type safety. However, when functions interact with other APIs—such as `JSONDecoder`—developers often face the burden of catching, mapping, and rethrowing errors manually. This leads to repetitive code and obscures intent. |
| 46 | + |
| 47 | +## altai's approach |
| 48 | + |
| 49 | +Altai introduces the `UpliftingErrors` protocol, allowing custom error enums to “uplift” foreign errors seamlessly: |
| 50 | + |
| 51 | +```swift |
| 52 | +enum CustomError: Error, UpliftingErrors { |
| 53 | + case oddNumber |
| 54 | + case uplifted(any Error) |
| 55 | +} |
| 56 | + |
| 57 | +func throwingIfOdd(_ number: String) throws(CustomError) -> Int { |
| 58 | + let number = try CustomError.uplift { |
| 59 | + try JSONDecoder().decode(Int.self, from: number.data(using: .utf8)!) |
| 60 | + } |
| 61 | + guard number % 2 == 0 else { throw .oddNumber } |
| 62 | + return number |
| 63 | +} |
| 64 | +``` |
| 65 | + |
| 66 | +Here, any error thrown by `JSONDecoder` is automatically uplifted into CustomError, eliminating the need for verbose catch-and-map logic. The result is cleaner, more maintainable code that preserves type safety while reducing friction. |
| 67 | + |
| 68 | +## Integration with Swift Package Manager |
| 69 | + |
| 70 | +altai is distributed via Swift Package Manager and can be added to any project with a single dependency declaration: |
| 71 | + |
| 72 | +```swift |
| 73 | +dependencies: [ |
| 74 | + .package(url: "https://github.com/csanfilippo/altai.git", from: "1.0.0") |
| 75 | +] |
| 76 | +``` |
| 77 | + |
| 78 | +## Learn more |
| 79 | + |
| 80 | +- Full documentation and usage examples are on [GitHub](https://github.com/csanfilippo/altai) |
| 81 | +- altai is index by [Swift Package Index](https://swiftpackageindex.com/csanfilippo/altai) |
0 commit comments