What should happen when a user tries to save an expense with no title, a negative amount, or one that blows straight through the month’s food budget? Returning an optional, as you did in the optionals lesson, tells the caller that it failed but not why, and Pocket Budget needs the why to show the right message. Swift’s error handling makes failure part of a function’s signature, with the reasons spelled out as types.
\nStart by listing the ways recording an expense can fail:
\nimport Foundation\n\nenum BudgetError: Error, Equatable {\n case emptyTitle\n case nonPositiveAmount\n case overLimit(by: Decimal)\n}Any type that conforms to Error can be thrown, and an enum with associated values is the natural fit: each case is one failure, and overLimit carries how far over the user would go. Error has no requirements; it marks the type as throwable. Equatable will help with tests in the last lesson.
A function that can fail says so with throws and stops with throw:
struct CategoryBudget {\n var limit: Decimal\n private(set) var spent: Decimal = 0\n\n mutating func record(title: String, amount: Decimal) throws {\n guard !title.trimmingCharacters(in: .whitespaces).isEmpty else {\n throw BudgetError.emptyTitle\n }\n guard amount > 0 else {\n throw BudgetError.nonPositiveAmount\n }\n let newTotal = spent + amount\n guard newTotal <= limit else {\n throw BudgetError.overLimit(by: newTotal - limit)\n }\n spent = newTotal\n }\n}guard and throw pair perfectly: each guard states a rule, and its else throws the matching error. private(set) lets anyone read spent but only the budget itself change it, so the only way to spend money is through record, which enforces the rules.
Every call to a throwing function must be marked with try. That keyword is for humans: scan a function for try and you see every line where control might leave early.
var food = CategoryBudget(limit: 50)\n\ndo {\n try food.record(title: \"Dinner\", amount: 62)\n print(\"Saved\")\n} catch BudgetError.overLimit(let by) {\n print(\"That's \\(by) over your food budget\")\n} catch {\n print(\"Couldn't save: \\(error)\")\n}When record throws, execution jumps straight to the first catch whose pattern matches, skipping print("Saved"). Catch clauses use the same pattern matching as switch, so you can bind associated values. The final bare catch handles everything else and gives you the error as a constant named error.
If a function can’t sensibly handle an error, it doesn’t have to. Mark it throws too, call with try and no do, and the error travels up to its caller.
Two shortcuts exist. try? converts the result into an optional: success gives a value, failure gives nil. try! asserts that the call can’t fail and crashes if it does, with the same risk as a force unwrap.
print(error) shows overLimit(by: 12), which is fine for a log and useless in an alert. Conform to LocalizedError to supply human text:
extension BudgetError: LocalizedError {\n var errorDescription: String? {\n switch self {\n case .emptyTitle: \"Give the expense a name.\"\n case .nonPositiveAmount: \"Enter an amount greater than zero.\"\n case .overLimit(let by): \"This puts you \\(by.formatted(.currency(code: \"USD\"))) over budget.\"\n }\n }\n}Now error.localizedDescription returns that sentence, ready for a SwiftUI alert.
Plain throws means “can throw any Error”. Swift 6 adds typed throws, where the signature names the exact type:
mutating func record(title: String, amount: Decimal) throws(BudgetError) {\n // same body; inside, `throw .emptyTitle` can drop the type name\n}The payoff is at the call site. When every try in a do block throws BudgetError, the error in catch is a BudgetError, not any Error, so you can switch over it exhaustively with no catch-all. Write do throws(BudgetError) to state that explicitly:
do throws(BudgetError) {\n try food.record(title: \"Snack\", amount: 100)\n} catch {\n switch error {\n case .emptyTitle: print(\"Give it a name\")\n case .nonPositiveAmount: print(\"Amount must be positive\")\n case .overLimit(let by): print(\"That's \\(by) over budget\")\n }\n}The cost is rigidity: once a function promises BudgetError, it can’t start throwing a decoding or network error without changing its signature and every caller. The Swift project’s own guidance is to keep untyped throws as the default and use typed throws inside a module where callers handle every case, as Pocket Budget’s validation does. For networking later in the course you’ll stay with plain throws, because those calls can fail in more ways than you control.
That completes the modelling section. You can now describe Pocket Budget’s data and its failures precisely. Next, you put that data on screen with SwiftUI.
\n","toc":[{"id":"sec-1","text":"Errors are enums","level":2},{"id":"sec-2","text":"throw and try","level":2},{"id":"sec-3","text":"Handling errors with do-catch","level":2},{"id":"sec-4","text":"try? and try!","level":2},{"id":"sec-5","text":"Messages users can read","level":2},{"id":"sec-6","text":"Typed throws in Swift 6","level":2}],"takeaways":["Model the ways an operation can fail as an enum that conforms toError, with associated values for the details.","Every call to a throwing function is marked with try, so readers can see exactly where control might jump out.","do-catch handles errors; catch clauses can pattern-match specific cases, and a final catch gets the rest as error.","try? turns failure into nil and throws away the reason, so use it only when the reason truly doesn’t matter.","Typed throws (throws(BudgetError)) fit code where callers handle every case; untyped throws stays the better default for public APIs."],"further":[{"title":"Error Handling","url":"https://docs.swift.org/swift-book/documentation/the-swift-programming-language/errorhandling/"},{"title":"LocalizedError","url":"https://developer.apple.com/documentation/foundation/localizederror"}],"quiz":[{"q":"func record(...) throws. What does let result = try? budget.record(title: "Tea", amount: 3) give you when it fails?
result.","why":"try? discards the error entirely; you only learn that something failed."},{"text":"nil, and the reason is lost.","why":"Correct. That’s the trade-off with try?, and why it suits only failures you’d ignore anyway."},{"text":"A crash with the error’s description.","why":"That’s try!. try? never crashes."}],"answer":1},{"q":"A function calls try budget.record(...) but has no do-catch. When does that compile?
throws, so the error propagates to its caller.","why":"Correct. Errors travel up the call chain until something catches them."},{"text":"Never; every try must sit inside a do block.","why":"A throwing function can let errors pass through to its caller without catching them."},{"text":"Always; uncaught errors are logged and ignored.","why":"Swift checks error handling at compile time. An uncaught error from a non-throwing function is a build error."}],"answer":0},{"q":"When is typed throws, such as throws(BudgetError), the better choice?
throws remains the default because it lets an API add new failure types later."},{"text":"For public library APIs that other teams depend on.","why":"That’s where the fixed error type hurts most; adding a failure later becomes a breaking change."},{"text":"For code inside your module where callers handle every case exhaustively.","why":"Correct. That’s where knowing the exact type pays off, with a switch and no catch-all."}],"answer":2}],"exercise":{"kind":"choice","options":["a","b","c","d"],"correct":["d"],"title":"Follow the errors","prompt":"This uses the CategoryBudget and BudgetError from the lesson: record throws .emptyTitle for a blank title, .nonPositiveAmount for an amount of zero or less, and .overLimit(by:) when the new total would pass the limit. Predict everything the loop prints.
var food = CategoryBudget(limit: 50)\nlet attempts: [(String, Decimal)] = [(\"Lunch\", 12), (\"\", 5), (\"Dinner\", 45)]\n\nfor (title, amount) in attempts {\n do {\n try food.record(title: title, amount: amount)\n print(\"Saved \\(title)\")\n } catch BudgetError.overLimit(let by) {\n print(\"Over by \\(by)\")\n } catch {\n print(\"Rejected: \\(error)\")\n }\n}\nprint(food.spent)spent after each attempt. Does a failed attempt change it?","The second attempt fails before the amount is even checked. Which guard comes first?","For the third attempt, the new total would be 12 + 45. How far is that over 50?"],"explanation":"Lunch passes every guard, so spent becomes 12 and the line prints “Saved Lunch”. The blank title fails the first guard; .emptyTitle doesn’t match the overLimit pattern, so the bare catch prints “Rejected: emptyTitle”. Dinner would bring the total to 57, so record throws .overLimit(by: 7) and the first catch prints “Over by 7”.
Because record throws before it assigns spent, the failed attempts change nothing, and the final line prints 12. Writing all the checks first and the mutation last is what makes the function safe to call again after a failure.
spent = newTotal runs, so the total never reaches 57."},"c":{"text":"Saved Lunch / Over by 7 / 12","why":"The blank title still produces output. It’s caught by the final bare catch, which prints “Rejected: emptyTitle”."},"d":{"text":"Saved Lunch / Rejected: emptyTitle / Over by 7 / 12","why":"Correct. Each failure is caught by the first matching clause, and failed attempts leave spent untouched."}}},"words":697,"readMinutes":3}