Error handling for network calls in iOS Swift - Practice Problems & Coding Challenges

Challenge - 5 Problems

❓ ui_behavior

intermediate

Handling network error UI update

You make a network call that can fail. Which option correctly updates the UI to show an error message when the call fails?

iOS Swift

func fetchData() {
  networkCall { result in
    switch result {
    case .success(let data):
      self.updateUI(with: data)
    case .failure(let error):
      // What to do here?
    }
  }
}

A DispatchQueue.global().async { self.errorLabel.text = error.localizedDescription }

B DispatchQueue.main.async { self.errorLabel.text = error.localizedDescription }

C print(error.localizedDescription)

D self.errorLabel.text = error.localizedDescription

💡 Hint

UI updates must happen on the main thread.

UI changes in iOS must be done on the main thread. Option B uses DispatchQueue.main.async to update the error label text safely. Option B updates UI on a background thread, which can cause issues. Option B updates UI on a global background thread, which is incorrect. Option B only prints the error and does not update the UI.

🧠 Conceptual

intermediate

Understanding URLSession error handling

What does the 'error' parameter in URLSession dataTask completion handler represent?

A The HTTP status code of the response

B The data returned from the server

C A client-side error such as network failure or request timeout

D An error returned by the server in the HTTP response body

💡 Hint

Think about what kind of errors happen before getting a response.

The 'error' parameter represents client-side errors like no internet connection or timeout. Server errors come as HTTP status codes in the response, not as this error parameter.

❓ lifecycle

advanced

Properly cancelling a network call on view disappear

You start a URLSession dataTask in a view controller. What is the best way to cancel the task when the view disappears to avoid memory leaks or unwanted callbacks?

A Do nothing; the system cancels tasks automatically

B Set task to nil inside viewDidDisappear method

C Call task.resume() inside viewWillDisappear method

D Call task.cancel() inside viewWillDisappear method

💡 Hint

Think about when you want to stop the network call cleanly.

Calling task.cancel() inside viewWillDisappear stops the network call and prevents callbacks after the view is gone. Setting task to nil does not cancel the task. The system does not cancel tasks automatically. Calling resume() starts or resumes the task, which is the opposite of cancel.

📝 Syntax

advanced

Correct error handling syntax in async network call

Which option correctly uses Swift's async/await syntax with error handling for a network call?

iOS Swift

func loadData() async {
  do {
    let data = try await fetchData()
    process(data)
  } catch {
    handle(error)
  }
}

A do { let data = try await fetchData(); process(data) } catch { handle(error) }

B let data = await fetchData() catch { handle(error) }

C try { let data = await fetchData() } catch { handle(error) }

D let data = try fetchData() await process(data)

💡 Hint

Remember the correct placement of try, await, and do-catch blocks.

Option A correctly wraps the try await call inside a do block and catches errors. Option A has invalid syntax mixing await and catch. Option A misuses try without await and wrong do-catch syntax. Option A misorders try and await and misses async context.

🔧 Debug

expert

Diagnosing error message on successful network calls

You notice your app shows an error message even when the network call succeeds. Which option is the most likely cause?

iOS Swift

URLSession.shared.dataTask(with: url) { data, response, error in
  if error != nil {
    print("Error occurred")
  }
  DispatchQueue.main.async {
    self.errorLabel.text = "Failed to load"
  }
}.resume()

A The errorLabel update is outside the error check, so it always shows failure even if no error

B The UI update runs regardless of error presence, so errorLabel always shows failure even on success

C The error check is incorrect; it should be if error == nil

D The network call is missing .resume() to start the task

💡 Hint

Look where the UI update code is placed relative to the error check.

The errorLabel.text update is outside the if error != nil block, so it runs always, showing failure even on success. This can confuse the user. The correct approach is to update UI only inside the error check. Option A describes the symptom but B pinpoints the cause. Option A is wrong logic. Option A is false because .resume() is present.