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:
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`)
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`.
> if err != nil return err