Error handling and exceptions in OOP

Junior

Essence

In classic OOP languages (Java, C#, C++) errors are exceptions: an object is thrown, the stack unwinds to the nearest catch, and any call may implicitly abort execution. Swift takes a different route: an error is a value, not an exception.

How it works in Swift

• Error is an empty protocol; errors are usually modelled as an enum with associated values or a struct.
• A function declares throws; the call must be marked with try. There are no hidden exit paths: try is visible in the code.
• Under the hood throws is an ordinary return through an extra register, with no stack unwinding and no exception tables: throwing is cheap.
• Typed throws (Swift 6): throws(PaymentError) puts the error type into the signature, catch becomes exhaustive and there is no boxing into any Error. Untyped throws is equivalent to throws(any Error).
• Result<Success, Failure> stores the outcome "for later" (callbacks, Combine); try? turns an error into nil, try! into a crash; defer runs cleanup on every exit path.
• An Objective-C NSException cannot be caught by Swift code: it is a bug, not an error; the same applies to fatalError/precondition.

import Foundation

enum PaymentError: Error {
    case insufficientFunds(missing: Decimal)
    case cardExpired
}

// Typed throws (Swift 6): the error type is part of the signature.
func charge(_ amount: Decimal, balance: Decimal) throws(PaymentError) {
    guard balance >= amount else {
        throw .insufficientFunds(missing: amount - balance)
    }
}

do {
    try charge(100, balance: 30)
} catch .insufficientFunds(let missing) {
    print("need \(missing) more")          // need 70 more
} catch {
    print("other: \(error)")
}

// Error as a value: Result keeps success/failure for later.
let result = Result { try charge(10, balance: 50) }
if case .failure(let e) = result { print(e) }

let maybe: Void? = try? charge(1, balance: 0)  // nil on failure
print(maybe == nil)                             // true

What the interviewer looks for

• Separating expected errors (network, validation: throws/Result) from programmer errors (a broken invariant: precondition, crash).
• Typed throws matter in library code and in embedded/performance-critical places; in app code any Error is usually enough.
• Relation to async: with async throws errors propagate through await just as through a normal call; a Task keeps its error behind the Result-like .value.