Error protocol conformance in Swift - Time & Space Complexity

Time Complexity: Error protocol conformance

O(1)

Understanding Time Complexity

When we make a type follow the Error protocol in Swift, it helps us handle errors clearly. But how does this affect how long our program takes to run?

We want to see how the time needed changes when we create and use errors this way.

Scenario Under Consideration

Analyze the time complexity of the following code snippet.

    enum FileError: Error {
      case notFound
      case unreadable
      case encodingFailed
    }

    func readFile(_ name: String) throws -> String {
      guard name == "data.txt" else { throw FileError.notFound }
      return "File content"
    }
    

This code defines an error type and a function that throws an error if the file name is wrong.

Identify Repeating Operations

Identify the loops, recursion, array traversals that repeat.

• Primary operation: Checking the file name and possibly throwing an error.
• How many times: This check happens once per function call.

How Execution Grows With Input

Explain the growth pattern intuitively.

Input Size (n)	Approx. Operations
10	1 check
100	1 check
1000	1 check

Pattern observation: Each call does one check, which takes constant time independent of input size.

Final Time Complexity

Time Complexity: O(1)

This means the time per function call is constant and does not grow with input size.

Common Mistake

[X] Wrong: "Making a type conform to Error makes the program slower in a big way."

[OK] Correct: Conforming to Error just adds a simple label to the type. It does not add loops or heavy work, so it does not slow down the program noticeably.

Interview Connect

Understanding how error types work and their cost helps you write clear and efficient Swift code. This skill shows you know how to balance safety and speed.

Self-Check

"What if the error type had associated values that needed extra work? How would the time complexity change?"

Practice

1. What is the main purpose of the Error protocol in Swift?

easy

A. To create network connections

B. To handle user interface events

C. To manage memory allocation automatically

D. To define custom error types that can be thrown and caught

Solution

1. Step 1: Understand the role of the Error protocol

   The Error protocol is designed to let developers define their own error types in Swift.

2. Step 2: Identify the purpose of custom error types

   Custom error types allow throwing and catching specific errors in code, improving error handling.

3. Final Answer:

   To define custom error types that can be thrown and caught -> Option D

4. Quick Check:

   Error protocol = custom error types [OK]

Hint: Error protocol is for creating your own error types [OK]

Common Mistakes:

• Confusing Error protocol with UI or memory management
• Thinking Error protocol manages network connections
• Assuming Error protocol is for general programming tasks

2. Which of the following is the correct way to declare an enum that conforms to the Error protocol?

easy

A. enum NetworkError: Error { case disconnected, timeout }

B. enum NetworkError { case disconnected, timeout }

C. enum NetworkError: String { case disconnected, timeout }

D. enum NetworkError: Int { case disconnected, timeout }

Solution

1. Step 1: Check enum conformance syntax

   To conform to the Error protocol, the enum must explicitly declare : Error after its name.

2. Step 2: Verify the enum cases

   The cases can be simple without raw values; raw values are optional and unrelated to Error conformance.

3. Final Answer:

   enum NetworkError: Error { case disconnected, timeout } -> Option A

4. Quick Check:

   Enum conforming to Error = enum Name: Error { cases } [OK]

Hint: Add ': Error' after enum name to conform [OK]

Common Mistakes:

• Omitting ': Error' conformance
• Using raw value types without conforming to Error
• Confusing enum raw types with protocol conformance

3. What will be the output of the following Swift code?

enum FileError: Error {
    case notFound
    case unreadable
}

func readFile(_ name: String) throws -> String {
    if name == "missing.txt" {
        throw FileError.notFound
    }
    return "File content"
}

 do {
    let content = try readFile("missing.txt")
    print(content)
} catch FileError.notFound {
    print("File not found error caught")
} catch {
    print("Other error")
}

medium

A. File not found error caught

B. File content

C. Other error

D. No output

Solution

1. Step 1: Analyze the function behavior

   The function throws FileError.notFound when the filename is "missing.txt".

2. Step 2: Check the do-catch block

   The catch block specifically catches FileError.notFound and prints "File not found error caught".

3. Final Answer:

   File not found error caught -> Option A

4. Quick Check:

   Throw and catch specific error = prints catch message [OK]

Hint: Throws matching catch block runs, prints its message [OK]

Common Mistakes:

• Expecting function to return normally
• Ignoring specific catch and expecting generic catch
• Confusing error thrown with error caught

4. Identify the error in the following Swift code snippet:

enum LoginError: Error {
    case invalidUsername
    case invalidPassword
}

func login(user: String, password: String) throws {
    if user.isEmpty {
        throw LoginError.invalidUsername
    } else if password.isEmpty {
        throw LoginError.invalidPassword
    }
}

try login(user: "", password: "1234")

medium

A. Function login should not throw errors

B. Missing do-catch block to handle the thrown error

C. Enum does not conform to Error protocol

D. Invalid enum case names

Solution

1. Step 1: Check enum conformance

   The enum correctly conforms to the Error protocol with valid cases.

2. Step 2: Analyze function call

   The function is called with try but outside a do-catch block or without try? or try!, causing a compile-time error.

3. Final Answer:

   Missing do-catch block to handle the thrown error -> Option B

4. Quick Check:

   Throwing function call needs do-catch or try? [OK]

Hint: Use do-catch when calling throwing functions [OK]

Common Mistakes:

• Calling throwing function without do-catch
• Assuming enum conformance is missing
• Misunderstanding error handling syntax

5. You want to create a custom error enum DatabaseError that conforms to Error and includes cases for connectionFailed, queryFailed, and timeout. Additionally, you want to add a computed property message that returns a user-friendly description for each case. Which of the following is the correct implementation?

hard

A. struct DatabaseError: Error {
var message: String
}

B. enum DatabaseError {
case connectionFailed
case queryFailed
case timeout

var message: String {
return "Error occurred"
}
}

C. enum DatabaseError: Error {
case connectionFailed
case queryFailed
case timeout

var message: String {
switch self {
case .connectionFailed: return "Connection failed"
case .queryFailed: return "Query failed"
case .timeout: return "Operation timed out"
}
}
}

D. enum DatabaseError: Error {
case connectionFailed(String)
case queryFailed(String)
case timeout(String)

var message: String {
return "Error"
}
}

Solution

1. Step 1: Confirm enum conforms to Error and defines cases

   enum DatabaseError: Error { case connectionFailed case queryFailed case timeout var message: String { switch self { case .connectionFailed: return "Connection failed" case .queryFailed: return "Query failed" case .timeout: return "Operation timed out" } } } correctly declares an enum conforming to Error with the required cases.

2. Step 2: Check computed property implementation

   The computed property message uses a switch on self to return descriptive strings for each case.

3. Final Answer:

   enum with computed property and switch -> Option C

4. Quick Check:

   Enum + Error + computed property with switch = enum DatabaseError: Error { case connectionFailed case queryFailed case timeout var message: String { switch self { case .connectionFailed: return "Connection failed" case .queryFailed: return "Query failed" case .timeout: return "Operation timed out" } } } [OK]

Hint: Use enum with switch in computed property for messages [OK]

Common Mistakes:

• Not conforming enum to Error
• Using struct instead of enum for error cases
• Ignoring switch on self in computed property