cybercyst/go
1
0
Fork 0
mirror of https://github.com/golang/go.git synced 2025-05-05 15:43:04 +00:00
Code Issues Actions Packages Projects Releases Wiki Activity

improve formatting

Florian Kaiser 2015-09-12 18:41:40 +02:00
parent 130898a9cf
commit 33a7823df6
1 changed files with 2 additions and 2 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
PanicAndRecover.md

@ -2,11 +2,11 @@
# Panic
The ` panic ` and ` recover ` functions behave similarly to exceptions and try/catch in some other languages in that a ` panic ` causes the program stack to begin unwinding and ` recover ` can stop it. Deferred functions are still executed as the stack unwinds. If ` recover ` is called inside such a deferred function, the stack stops unwinding and ` recover ` returns the value (as an ` interface{ `}) that was passed to ` panic `. The runtime will also panic in extraordinary circumstances, such as indexing an array or slice out-of-bounds. If a ` panic ` causes the stack to unwind outside of any executing goroutine (e.g. ` main ` or the top-level function given to ` go ` fail to recover from it), the program exits with a stack trace of all executing goroutines. A ` panic ` cannot be ` recover `ed by a different goroutine.
The `panic` and `recover` functions behave similarly to exceptions and try/catch in some other languages in that a `panic` causes the program stack to begin unwinding and `recover` can stop it. Deferred functions are still executed as the stack unwinds. If `recover` is called inside such a deferred function, the stack stops unwinding and `recover` returns the value (as an `interface{}`) that was passed to `panic`. The runtime will also panic in extraordinary circumstances, such as indexing an array or slice out-of-bounds. If a `panic` causes the stack to unwind outside of any executing goroutine (e.g. `main` or the top-level function given to `go` fail to recover from it), the program exits with a stack trace of all executing goroutines. A `panic` cannot be `recover`ed by a different goroutine.
# Usage in a Package
By convention, no explicit panic() should be allowed to cross a package boundary. Indicating error conditions to callers should be done by returning error value. Within a package, however, especially if there are deeply nested calls to non-exported functions, it can be useful (and improve readability) to use panic to indicate error conditions which should be translated into error for the calling function. Below is an admittedly contrived example of a way in which a nested function and an exported function may interact via this panic-on-error relationship.
By convention, no explicit `panic()` should be allowed to cross a package boundary. Indicating error conditions to callers should be done by returning error value. Within a package, however, especially if there are deeply nested calls to non-exported functions, it can be useful (and improve readability) to use panic to indicate error conditions which should be translated into error for the calling function. Below is an admittedly contrived example of a way in which a nested function and an exported function may interact via this panic-on-error relationship.
```go
// A ParseError indicates an error in converting a word into an integer.