Errors are a normal part of software development.
An API request may fail. A file may not exist. A user may enter invalid data. A payment may be rejected. JSON decoding may fail. A database operation may encounter a problem.
A good Swift application should not simply assume that every operation will succeed.
Instead, it should be able to:
- Detect an error
- Describe what went wrong
- Pass the error to the appropriate code
- Handle the error safely
- Continue running when recovery is possible
Swift provides a powerful built-in error-handling system for this purpose.
The most important keywords are:
throw
throws
try
do
catch
You will also encounter:
try?
try!
defer
In this guide, you will learn how Swift error handling works from the absolute basics through practical examples.
What Is Error Handling in Swift?
Error handling is the process of responding to unexpected or unsuccessful situations during program execution.
Suppose you create a login function.
Normally, you expect:
Email + Password
↓
Login
↓
Success
But several things could go wrong:
Login
│
├── Invalid email
├── Wrong password
├── Account disabled
├── No internet
└── Server error
Instead of ignoring these situations, Swift allows us to represent them as errors.
For example:
enum LoginError: Error {
case invalidEmail
case incorrectPassword
}
Now your application can detect and handle each error separately.
Why Is Error Handling Important?
Without proper error handling, an application may:
- Crash unexpectedly
- Show incorrect information
- Leave operations incomplete
- Provide a poor user experience
- Make debugging difficult
- Hide important failures
Proper error handling helps applications become:
- Safer
- More predictable
- Easier to debug
- Easier to maintain
- More user-friendly
For example, instead of letting an operation fail silently, your application can show:
Unable to connect to the server.
Please check your internet connection.
That is much better than simply doing nothing.
Swift Error Handling Keywords
Before writing code, understand the main keywords.
Error
↓
throw
↓
throws
↓
try
↓
do
↓
catch
Their basic responsibilities are:
throw
Used to generate or throw an error.
throws
Marks a function that can throw an error.
try
Used when calling a throwing function.
do
Creates a scope in which throwing code can be executed and handled.
catch
Handles an error thrown from the associated do block.
We will now understand each one in detail.
The Error Protocol in Swift
In Swift, a throwable error must conform to the built-in:
Error
protocol.
A very common approach is to create an enum.
Example:
enum LoginError: Error {
case invalidEmail
case incorrectPassword
case accountBlocked
}
Now LoginError can be thrown.
Each case represents a different failure condition.
Why Use Enums for Errors?
Enums are useful because an operation often has a known set of possible failures.
For example, a withdrawal operation might fail because:
Invalid Amount
Insufficient Balance
Account Blocked
Daily Limit Exceeded
These can be represented clearly:
enum WithdrawalError: Error {
case invalidAmount
case insufficientBalance
case accountBlocked
case dailyLimitExceeded
}
This makes the possible errors easy to understand and handle.
Understanding throw
The throw keyword is used when your code detects an error and wants to stop normal execution of the current throwing scope.
Example:
enum AgeError: Error {
case underAge
}
Create a function:
func verifyAge(_ age: Int) throws {
if age < 18 {
throw AgeError.underAge
}
print("Age verified")
}
Notice:
throw AgeError.underAge
If age is below 18, Swift throws the error.
Normal execution of the function stops at that point.
Understanding throws
If a function can throw an error, it must declare that capability using:
throws
Example:
func verifyAge(_ age: Int) throws {
}
The basic syntax is:
func functionName() throws {
}
For a function returning a value:
func functionName() throws -> String {
}
throws tells the caller:
This function may fail with an error, so the caller must deal with that possibility.
Understanding try
When calling a throwing function, you use:
try
For example:
try verifyAge(20)
Why is try required?
Because Swift wants the possibility of failure to be explicit.
If a function can throw an error, calling it should visibly indicate that fact.
Understanding do
A do block creates a scope in which you can execute throwing code.
Example:
do {
try verifyAge(20)
}
However, if an error occurs, you normally need a catch block to handle it.
Understanding catch
catch handles errors thrown from a do block.
Example:
do {
try verifyAge(15)
} catch {
print("Age verification failed")
}
Output:
Age verification failed
The complete pattern is:
do {
try someThrowingFunction()
} catch {
// Handle error
}
How do, try, catch and throw Work Together?
Consider:
enum LoginError: Error {
case incorrectPassword
}
Function:
func login(password: String) throws {
if password != "swift123" {
throw LoginError.incorrectPassword
}
print("Login successful")
}
Call:
do {
try login(password: "wrongPassword")
} catch {
print("Login failed")
}
Flow:
login()
↓
Check password
↓
Invalid?
↓
throw error
↓
Execution returns to caller
↓
catch receives error
↓
Handle failure
Handling Specific Errors
A generic catch handles any error.
But often you want different behavior for different errors.
Example:
enum LoginError: Error {
case invalidEmail
case incorrectPassword
case accountBlocked
}
Function:
func login(
email: String,
password: String
) throws {
if !email.contains("@") {
throw LoginError.invalidEmail
}
if password != "swift123" {
throw LoginError.incorrectPassword
}
print("Login successful")
}
Handle specific cases:
do {
try login(
email: "alex@example.com",
password: "wrong"
)
} catch LoginError.invalidEmail {
print("Please enter a valid email")
} catch LoginError.incorrectPassword {
print("Password is incorrect")
} catch LoginError.accountBlocked {
print("Your account has been blocked")
} catch {
print("Unknown login error")
}
This gives you precise control over each failure.
The Generic catch
You will often end a group of specific catch clauses with:
catch {
}
This handles errors not matched earlier.
Example:
do {
try performOperation()
} catch NetworkError.noInternet {
print("No internet connection")
} catch {
print("Something else went wrong")
}
Inside a generic catch, Swift provides the caught value through:
error
Example:
catch {
print(error)
}
Catching an Error into a Custom Variable
You can also explicitly bind the error.
do {
try performOperation()
} catch let error {
print(error)
}
This can make the code easier to understand when you need to inspect or pass the error elsewhere.
Errors with Associated Values
Swift enums can store additional information using associated values.
This is extremely useful for errors.
Example:
enum ValidationError: Error {
case emptyField(field: String)
case tooShort(
field: String,
minimumLength: Int
)
}
Throw:
func validateUsername(
_ username: String
) throws {
if username.isEmpty {
throw ValidationError.emptyField(
field: "Username"
)
}
if username.count < 4 {
throw ValidationError.tooShort(
field: "Username",
minimumLength: 4
)
}
}
Handle:
do {
try validateUsername("ab")
} catch ValidationError.emptyField(let field) {
print("\(field) cannot be empty")
} catch ValidationError.tooShort(
let field,
let minimumLength
) {
print(
"\(field) must contain at least \(minimumLength) characters"
)
} catch {
print("Validation failed")
}
Associated values allow your errors to carry useful context.
Practical Example: Division Error
Division provides a simple example.
Define:
enum MathError: Error {
case divisionByZero
}
Function:
func divide(
_ first: Double,
by second: Double
) throws -> Double {
guard second != 0 else {
throw MathError.divisionByZero
}
return first / second
}
Use:
do {
let result = try divide(
10,
by: 2
)
print(result)
} catch MathError.divisionByZero {
print("Cannot divide by zero")
}
Output:
5.0
If:
try divide(10, by: 0)
the error is thrown instead.
Throwing Functions with Return Values
A throwing function can still return a normal value when successful.
Example:
enum UserError: Error {
case userNotFound
}
Function:
func findUser(
id: Int
) throws -> String {
guard id == 1 else {
throw UserError.userNotFound
}
return "Alex"
}
Use:
do {
let user = try findUser(id: 1)
print(user)
} catch {
print("Unable to find user")
}
If successful:
Alex
If unsuccessful, the function throws instead of returning the normal result.
Using guard with throw
guard works very naturally with throwing functions.
Example:
enum RegistrationError: Error {
case invalidEmail
case weakPassword
}
Function:
func register(
email: String,
password: String
) throws {
guard email.contains("@") else {
throw RegistrationError.invalidEmail
}
guard password.count >= 8 else {
throw RegistrationError.weakPassword
}
print("Registration successful")
}
This style is often cleaner than deeply nested if statements.
Multiple Error Conditions
One function can throw different errors.
Example:
enum ATMError: Error {
case invalidAmount
case insufficientBalance
case dailyLimitExceeded
}
Function:
func withdraw(
amount: Double,
balance: Double
) throws -> Double {
guard amount > 0 else {
throw ATMError.invalidAmount
}
guard amount <= 10_000 else {
throw ATMError.dailyLimitExceeded
}
guard amount <= balance else {
throw ATMError.insufficientBalance
}
return balance - amount
}
Handle:
do {
let remainingBalance = try withdraw(
amount: 500,
balance: 2000
)
print(
"Remaining balance: \(remainingBalance)"
)
} catch ATMError.invalidAmount {
print("Enter a valid amount")
} catch ATMError.insufficientBalance {
print("Insufficient balance")
} catch ATMError.dailyLimitExceeded {
print("Daily withdrawal limit exceeded")
} catch {
print("Withdrawal failed")
}
What Is try? in Swift?
Sometimes you don’t need detailed information about why an operation failed.
You only need to know whether it produced a value.
Swift provides:
try?
Example:
let result = try? divide(
10,
by: 2
)
If the operation succeeds, result contains the returned value as an optional.
If the operation fails:
let result = try? divide(
10,
by: 0
)
the result becomes:
nil
instead of propagating the error.
When Should You Use try?
try? can be useful when:
- Failure is acceptable
- You don’t need the exact error
nilis enough to represent failure- You want concise optional-based handling
Example:
if let user = try? findUser(id: 1) {
print(user)
} else {
print("User unavailable")
}
What Is try! in Swift?
Swift also provides:
try!
Example:
let result = try! divide(
10,
by: 2
)
try! tells Swift:
I am certain this operation will not throw an error.
If it does throw, the application traps at runtime.
For example:
let result = try! divide(
10,
by: 0
)
will fail at runtime.
Why Should Beginners Be Careful with try!?
try! removes normal error recovery.
It should only be used when failure is genuinely impossible or represents a programmer/configuration error that should never occur in a valid build.
In general application code, prefer:
do {
try ...
} catch {
...
}
or, when the exact error is irrelevant:
try?
instead of casually using try!.
try vs try? vs try!
A useful comparison:
| Syntax | What Happens on Error? | Typical Use |
|---|---|---|
try | Error is propagated/handled normally | Standard error handling |
try? | Error becomes nil | Failure details aren’t needed |
try! | Runtime trap if an error occurs | Only when failure is guaranteed not to happen |
Example:
try loadData()
Normal throwing call.
let data = try? loadData()
Failure becomes nil.
let data = try! loadData()
Failure causes a runtime trap.
Propagating Errors
Not every function needs to catch an error immediately.
A function can allow the error to propagate to its caller.
Example:
func loadUser() throws -> String {
return try findUser(id: 1)
}
Notice that loadUser() does not use do-catch.
Instead, it is itself marked:
throws
The error can continue to the next caller.
Eventually, some appropriate layer should handle it.
Error Propagation Flow
Imagine:
View
↓
ViewModel
↓
Service
↓
API
An API operation might throw an error.
The service may propagate it:
API
↓
throws
↓
Service
↓
throws
↓
ViewModel
↓
catch
This allows errors to be handled at a layer that knows how to respond appropriately.
For example, the ViewModel may convert the error into a user-facing message.
Throwing Initializers
Initializers can also throw.
Example:
enum UserCreationError: Error {
case emptyName
}
Class:
class User {
let name: String
init(name: String) throws {
guard !name.isEmpty else {
throw UserCreationError.emptyName
}
self.name = name
}
}
Create:
do {
let user = try User(
name: "Alex"
)
print(user.name)
} catch {
print("Unable to create user")
}
A throwing initializer is useful when object creation requires validation.
Error Handling with JSON Decoding
One of the most common real-world uses of try is JSON decoding.
Suppose:
struct User: Codable {
let id: Int
let name: String
}
Decode:
do {
let user = try JSONDecoder().decode(
User.self,
from: data
)
print(user.name)
} catch {
print("Unable to decode user")
}
decode() is a throwing method because JSON data may be:
- Invalid
- Missing required fields
- Using unexpected types
- Corrupted
- Structured differently than expected
Handling DecodingError
Instead of handling every decoding failure generically, you can inspect DecodingError.
Common cases include:
keyNotFound
typeMismatch
valueNotFound
dataCorrupted
Example:
do {
let user = try JSONDecoder().decode(
User.self,
from: data
)
print(user)
} catch DecodingError.keyNotFound(
let key,
let context
) {
print("Missing key: \(key.stringValue)")
print(context.debugDescription)
} catch DecodingError.typeMismatch(
let type,
let context
) {
print("Type mismatch: \(type)")
print(context.debugDescription)
} catch {
print(error)
}
This can make debugging API model problems much easier.
Error Handling with File Operations
File operations can also fail.
For example:
do {
let content = try String(
contentsOfFile: filePath,
encoding: .utf8
)
print(content)
} catch {
print(
"Unable to read file: \(error)"
)
}
Possible reasons include:
File does not exist
Permission denied
Invalid encoding
Storage problem
Throwing APIs make these failures explicit.
Error Handling with Async/Await
Modern Swift applications frequently combine error handling with concurrency.
An asynchronous throwing function uses:
async throws
Example:
func fetchUser() async throws -> User {
// Network request
return User(
id: 1,
name: "Alex"
)
}
Call it with:
do {
let user = try await fetchUser()
print(user.name)
} catch {
print("Unable to fetch user")
}
Notice:
try await
The operation is both:
- Asynchronous
- Capable of throwing
Practical Network Example
A simplified networking function might look like:
enum NetworkError: Error {
case invalidURL
case invalidResponse
}
Function:
func fetchData() async throws -> Data {
guard let url = URL(
string: "https://example.com/users"
) else {
throw NetworkError.invalidURL
}
let (data, response) =
try await URLSession.shared.data(
from: url
)
guard let httpResponse =
response as? HTTPURLResponse,
(200...299).contains(
httpResponse.statusCode
)
else {
throw NetworkError.invalidResponse
}
return data
}
Call:
do {
let data = try await fetchData()
print(
"Received \(data.count) bytes"
)
} catch NetworkError.invalidURL {
print("Invalid URL")
} catch NetworkError.invalidResponse {
print("Server returned an invalid response")
} catch {
print(
"Network request failed: \(error)"
)
}
Creating User-Friendly Error Messages
Technical error names are useful to developers but not always suitable for users.
For example:
NetworkError.invalidResponse
is less useful to an end user than:
We couldn't load your data.
Please try again.
You can give custom errors human-readable descriptions.
One approach is LocalizedError.
Using LocalizedError
Example:
enum LoginError: LocalizedError {
case invalidEmail
case incorrectPassword
case accountBlocked
var errorDescription: String? {
switch self {
case .invalidEmail:
return "Please enter a valid email address."
case .incorrectPassword:
return "The password you entered is incorrect."
case .accountBlocked:
return "Your account has been blocked."
}
}
}
Use:
do {
try login(
email: "alex@example.com",
password: "wrong"
)
} catch {
print(
error.localizedDescription
)
}
Now your custom errors can provide clearer messages.
Using defer with Error Handling
defer isn’t itself an error-handling keyword, but it is extremely useful when cleanup must happen regardless of whether an operation succeeds or throws.
Example:
func processFile() throws {
print("Opening file")
defer {
print("Closing file")
}
try performFileOperation()
print("Processing complete")
}
The defer block runs when the current scope exits.
That includes cases where the scope exits because of a thrown error.
This is useful for cleanup tasks such as:
- Closing resources
- Releasing locks
- Ending temporary operations
- Resetting state
Multiple defer Statements
If multiple defer blocks exist in the same scope, they execute in reverse order.
Example:
func test() {
defer {
print("First defer")
}
defer {
print("Second defer")
}
print("Function body")
}
Output:
Function body
Second defer
First defer
Remember:
defer = cleanup when scope exits
Result vs throws
Swift also provides:
Result<Success, Failure>
which represents either:
Success
or
Failure
Example:
enum LoginError: Error {
case invalidCredentials
}
Result:
let result:
Result<String, LoginError> =
.success("Alex")
Handle:
switch result {
case .success(let user):
print(user)
case .failure(let error):
print(error)
}
When Should You Use throws?
throws works naturally for operations where failure interrupts normal control flow.
Example:
func loadUser() throws -> User
Call:
let user = try loadUser()
This is often straightforward and readable.
When Is Result Useful?
Result can be useful when success/failure needs to be stored, passed around, or represented as a value.
For example:
var latestResult:
Result<User, NetworkError>?
It is also common in callback-based APIs.
With modern async/await APIs, async throws is often a natural choice for asynchronous operations.
Error Handling in a ViewModel
Consider:
enum UserServiceError: LocalizedError {
case noInternet
case serverError
var errorDescription: String? {
switch self {
case .noInternet:
return "Please check your internet connection."
case .serverError:
return "The server is currently unavailable."
}
}
}
Service:
protocol UserService {
func fetchUsers() async throws -> [User]
}
ViewModel:
@MainActor
final class UserViewModel {
private let service: any UserService
var users: [User] = []
var errorMessage: String?
init(service: any UserService) {
self.service = service
}
func loadUsers() async {
do {
users = try await service.fetchUsers()
errorMessage = nil
} catch {
errorMessage =
error.localizedDescription
}
}
}
This creates a clean separation:
Service
↓
Throws technical/application error
ViewModel
↓
Handles error
UI
↓
Displays appropriate state/message
Real-World Example: Payment Processing
Define errors:
enum PaymentError: LocalizedError {
case invalidAmount
case insufficientFunds
case paymentDeclined
var errorDescription: String? {
switch self {
case .invalidAmount:
return "Please enter a valid payment amount."
case .insufficientFunds:
return "Insufficient funds."
case .paymentDeclined:
return "Your payment was declined."
}
}
}
Function:
func processPayment(
amount: Double,
balance: Double
) throws {
guard amount > 0 else {
throw PaymentError.invalidAmount
}
guard amount <= balance else {
throw PaymentError.insufficientFunds
}
print(
"Payment of \(amount) completed"
)
}
Call:
do {
try processPayment(
amount: 500,
balance: 200
)
} catch {
print(
error.localizedDescription
)
}
Output:
Insufficient funds.
Real-World Example: Registration Validation
Define:
enum RegistrationError: LocalizedError {
case emptyName
case invalidEmail
case weakPassword
var errorDescription: String? {
switch self {
case .emptyName:
return "Name cannot be empty."
case .invalidEmail:
return "Please enter a valid email."
case .weakPassword:
return "Password must contain at least 8 characters."
}
}
}
Validation:
func validateRegistration(
name: String,
email: String,
password: String
) throws {
guard !name.isEmpty else {
throw RegistrationError.emptyName
}
guard email.contains("@") else {
throw RegistrationError.invalidEmail
}
guard password.count >= 8 else {
throw RegistrationError.weakPassword
}
}
Use:
do {
try validateRegistration(
name: "Alex",
email: "alex@example.com",
password: "swift123"
)
print("Registration data is valid")
} catch {
print(
error.localizedDescription
)
}
Real-World Example: JSON API
Model:
struct User: Codable {
let id: Int
let name: String
let email: String
}
Custom errors:
enum APIError: LocalizedError {
case invalidURL
case invalidResponse
case requestFailed
var errorDescription: String? {
switch self {
case .invalidURL:
return "The request URL is invalid."
case .invalidResponse:
return "The server returned an invalid response."
case .requestFailed:
return "Unable to complete the request."
}
}
}
Service:
func fetchUsers() async throws -> [User] {
guard let url = URL(
string: "https://example.com/users"
) else {
throw APIError.invalidURL
}
let (data, response) =
try await URLSession.shared.data(
from: url
)
guard let httpResponse =
response as? HTTPURLResponse,
(200...299).contains(
httpResponse.statusCode
)
else {
throw APIError.invalidResponse
}
return try JSONDecoder().decode(
[User].self,
from: data
)
}
Caller:
do {
let users =
try await fetchUsers()
print(users)
} catch {
print(
error.localizedDescription
)
}
This combines:
async
await
throws
try
do
catch
JSON decoding
custom errors
in a practical Swift pattern.
Common Mistake: Forgetting try
This won’t compile:
let user = findUser(id: 1)
if findUser is declared with:
throws
You need:
let user = try findUser(id: 1)
and the error must be handled or propagated appropriately.
Common Mistake: Using try! Everywhere
Avoid:
let data = try! loadData()
simply because it makes the compiler error disappear.
If loadData() throws at runtime, the program traps.
Use real error handling when failure is realistically possible.
Common Mistake: Catching Everything Without Doing Anything
Avoid:
do {
try loadData()
} catch {
}
The error disappears silently.
At minimum, consider:
- Logging it
- Updating application state
- Showing a user-facing message
- Retrying when appropriate
- Propagating it to another layer
Common Mistake: Showing Raw Technical Errors to Users
Avoid displaying developer-oriented information directly in production UI.
For example:
DecodingError.keyNotFound(...)
is useful for developers.
A user may instead need:
We couldn't load this information.
Please try again.
Keep technical logging and user messaging separate.
Common Mistake: Using Errors for Normal Control Flow
Errors should generally represent exceptional or failure conditions.
For expected states, Swift features such as:
Bool
Optional
Enum
may communicate intent more clearly.
For example, checking whether a list is empty usually does not require throwing an error.
Common Mistake: Creating One Generic Error for Everything
Avoid designing every failure as:
enum AppError: Error {
case somethingWentWrong
}
This provides very little information.
Prefer meaningful errors such as:
enum NetworkError: Error {
case noInternet
case timeout
case invalidResponse
}
Specific errors are easier to:
- Debug
- Handle
- Test
- Convert into useful messages
Best Practices for Swift Error Handling
Keep these principles in mind:
- Create meaningful error types.
- Use enums when an operation has a known set of failure cases.
- Add associated values when the error needs context.
- Use
throwsfor operations that can legitimately fail. - Handle errors at a layer that knows what to do with them.
- Use
try?only when losing the exact error is acceptable. - Avoid unnecessary
try!. - Use
LocalizedErrorwhen errors need human-readable descriptions. - Keep developer logs separate from user-facing messages.
- Test both successful and failing paths.
- Use
deferwhen cleanup must happen as a scope exits. - Prefer clear, specific errors over vague failures.
Swift Error Handling Cheat Sheet
Define an Error
enum AppError: Error {
case invalidData
}
Throw an Error
throw AppError.invalidData
Throwing Function
func loadData() throws {
}
Call Throwing Function
try loadData()
Handle Error
do {
try loadData()
} catch {
print(error)
}
Specific Catch
catch AppError.invalidData {
}
Optional Try
let result = try? loadData()
Forced Try
let result = try! loadData()
Throwing Return Function
func fetchUser() throws -> User {
}
Async Throwing Function
func fetchUser() async throws -> User {
}
Async Throwing Call
let user =
try await fetchUser()
Cleanup
defer {
}
Practice Exercise 1: Age Verification
Create:
enum AgeError: Error {
case underAge
}
Create:
func verifyAge(_ age: Int) throws
Throw an error when the age is below 18.
Handle it with do-catch.
Practice Exercise 2: Calculator
Create:
enum CalculatorError: Error {
case divisionByZero
}
Create:
func divide(
_ first: Double,
by second: Double
) throws -> Double
Test both:
10 ÷ 2
10 ÷ 0
Practice Exercise 3: Login Validation
Create errors for:
Invalid Email
Empty Password
Incorrect Password
Then build a throwing login-validation function.
Handle each error separately.
Practice Exercise 4: Bank Withdrawal
Create:
enum BankError: Error {
case invalidAmount
case insufficientBalance
}
Create a withdrawal function that returns the remaining balance or throws an error.
Practice Exercise 5: JSON Decoding
Create a Codable user model.
Decode JSON using:
JSONDecoder().decode()
Handle:
keyNotFound
typeMismatch
dataCorrupted
errors.
Practice Exercise 6: Async API Request
Create:
func fetchData() async throws -> Data
Handle it using:
do {
let data = try await fetchData()
} catch {
}
This is especially useful practice before building real iOS networking layers.
Frequently Asked Questions
What is error handling in Swift?
Error handling is Swift’s mechanism for detecting, propagating, and responding to failures during program execution.
The primary keywords are:
throw
throws
try
do
catch
What does throw do in Swift?
throw generates an error and stops normal execution of the current throwing scope.
Example:
throw LoginError.invalidEmail
What does throws mean?
throws marks a function or initializer that can throw an error.
Example:
func login() throws {
}
What does try mean?
try is used when calling an operation that can throw.
Example:
try login()
What is do-catch?
do-catch allows you to execute throwing code and handle errors.
do {
try login()
} catch {
print(error)
}
What is the difference between throw and throws?
throw actually throws an error:
throw AppError.invalidData
throws declares that a function can throw:
func loadData() throws {
}
What is the difference between try, try? and try!?
try uses normal Swift error propagation.
try? converts failure into nil.
try! assumes failure cannot happen and traps if an error is thrown.
Can Swift enums be errors?
Yes.
Enums commonly conform to the Error protocol.
Example:
enum LoginError: Error {
case invalidEmail
}
Can a function return a value and throw an error?
Yes.
Example:
func fetchUser() throws -> User
It either returns a User or throws before returning normally.
Can an initializer throw?
Yes.
Example:
init(name: String) throws
This is useful when object creation requires validation.
Can async functions throw errors?
Yes.
Use:
async throws
and call them using:
try await
What is LocalizedError?
LocalizedError is a protocol that lets custom errors provide localized human-readable descriptions and related information.
It is useful when converting application errors into user-facing messages.
What is defer?
defer schedules code to execute when the current scope exits.
It is commonly useful for cleanup that should happen whether an operation succeeds or throws.
Should I use try! in production applications?
Only when you can genuinely guarantee that the operation cannot throw in a valid execution path.
For normal runtime failures, use proper error handling instead.
Should every error be caught immediately?
No.
Errors can propagate through multiple throwing functions until they reach a layer that can meaningfully handle them.
What Should You Learn After Swift Error Handling?
After understanding Swift error handling, a useful learning path is:
Swift Error Handling
↓
Codable & JSON
↓
URLSession
↓
Async/Await
↓
Swift Concurrency
↓
Networking Layer
↓
Dependency Injection
↓
Unit Testing
↓
SwiftUI Error States
These concepts frequently work together in real iOS applications.
Final Thoughts
Swift’s error-handling system makes failure an explicit part of your code.
The core flow is simple:
Define Error
↓
Detect Failure
↓
throw
↓
throws
↓
try
↓
do
↓
catch
↓
Recover / Inform User
Remember the main keywords:
throw
throws
try
do
catch
Then learn the supporting tools:
try?
try!
defer
LocalizedError
async throws
A simple example summarizes the entire concept:
enum LoginError: Error {
case incorrectPassword
}
func login(
password: String
) throws {
guard password == "swift123" else {
throw LoginError.incorrectPassword
}
print("Login successful")
}
do {
try login(
password: "wrong"
)
} catch LoginError.incorrectPassword {
print("Incorrect password")
} catch {
print("Something went wrong")
}
The most important idea to remember is:
Swift error handling separates the code that detects a failure from the code that decides how that failure should be handled.
Once you understand throw, throws, try, do, and catch, you have the foundation needed to handle validation, networking, JSON decoding, file operations, database failures, and many other real-world Swift application errors safely.
