[fakwandi_priv]

From what I can read Swift gives you a stack trace which is good. At the moment I’m using Go where that stack is only generated where the panic is triggered, which could be much higher up. Makes it a lot more unwieldy to figure out where an error happens because everyone uses:

> if err != nil return err

[nielsbot]

This is built in to the language.

When you call code that can throw (return an error via the special return path) you either have to handle it or make the enclosing context also throwing.

Assuming `canThrow()`, a function that might throw an `Error` type:

    func canThrow() throws {
        ...
    }

Call canThrow(), don't handle errors, just rethrow them

    func mightThrow() throws {
        try canThrow() // errors thrown from here will be thrown out of `mightThrow()`
        ...
    }

Alternatively, catch the errors and handle them as you wish:

    func mightThrow() throws {
        do {
            try canThrow()
        } catch {
            ...handle error here
            ...or `throw` another Error type of your choosing 
        }
        ...
    }

There are a few more ways to handle throwing calls.. For example

- `try?` (ignore error result, pretend result was `nil`)

- `try!` (fail fatally on error result)

[mayoff]

Swift doesn't capture a stack trace in the `Error` object, but Xcode can break when an error is thrown if you set a “Swift Error Breakpoint”, and the debugger will show you the stack trace. Under the hood it just sets breakpoints on the runtime functions `swift_willThrow` and `swift_willThrowTypedImpl`.