3 回答

TA貢獻(xiàn)1827條經(jīng)驗(yàn) 獲得超4個(gè)贊
有什么方法可以快速找到此錯(cuò)誤來自哪個(gè)文件/行?
除非是無法恢復(fù)的恐慌,否則不會(huì)打印默認(rèn)堆棧。
一般來說,地鼠是否有提示/技巧可以從這個(gè)字符串錯(cuò)誤消息中快速找到問題的根源?這是大多數(shù) go 項(xiàng)目的堆棧跟蹤方式,還是應(yīng)該遵循任何最佳實(shí)踐?
通常,您需要檢查大多數(shù)函數(shù)調(diào)用的錯(cuò)誤返回。有不止一種方法可以做到這一點(diǎn)。我通常使用標(biāo)準(zhǔn)庫包log打印帶有文件和行號(hào)的錯(cuò)誤日志,以便在簡單程序中進(jìn)行調(diào)試。例如:
package main
import "log"
import "errors"
func init() { log.SetFlags(log.Lshortfile | log.LstdFlags) }
func callFunc() error {
return errors.New("error")
}
func main() {
if err := callFunc(); err != nil {
log.Println(err)
}
}
http://play.golang.org/p/0iytNw7eZ7
輸出:
2009/11/10 23:00:00 main.go:14: error
此外,還有一些功能可以打印或檢索標(biāo)準(zhǔn)庫中的當(dāng)前堆棧runtime/debug,例如https://golang.org/pkg/runtime/debug/#PrintStack
有許多社區(qū)努力使錯(cuò)誤處理更容易,您可以在 GoDoc 中搜索錯(cuò)誤:https ://godoc.org/ ? q = error

TA貢獻(xiàn)1812條經(jīng)驗(yàn) 獲得超5個(gè)贊
您嘗試的解決方案:查找產(chǎn)生錯(cuò)誤的代碼段以修復(fù)代碼。
您的實(shí)際問題:的內(nèi)容event.json
。
這稱為XY 問題
Invoke 需要一個(gè) json 對(duì)象,您正在傳遞一個(gè) json 數(shù)組。解決這個(gè)問題,你的問題就消失了!
$ echo -n '{ "value": "Tobi the ferret" }' | apex invoke uppercase
文檔的相關(guān)部分:調(diào)用函數(shù)
這就是產(chǎn)生錯(cuò)誤的代碼:Github
是的,Go 確實(shí)有堆棧跟蹤!閱讀Dave Cheneys 關(guān)于錯(cuò)誤和異常的博文。

TA貢獻(xiàn)1875條經(jīng)驗(yàn) 獲得超5個(gè)贊
當(dāng) a發(fā)生時(shí),Go確實(shí)會(huì)產(chǎn)生堆棧跟蹤panic,從而使程序崩潰。如果代碼panic()直接調(diào)用就會(huì)發(fā)生這種情況,通常在以下情況下:
if err != nil {
panic("it broke")
}
或者,當(dāng)發(fā)生運(yùn)行時(shí)錯(cuò)誤時(shí):
a := []int{1, 2, 3}
b := a[12] // index out of range
這是一個(gè)最小的例子:
package main
func main() {
panic("wtf?!")
}
輸出:
panic: wtf?!
goroutine 1 [running]:
panic(0x94e60, 0x1030a040)
/usr/local/go/src/runtime/panic.go:464 +0x700
main.main()
/tmp/sandbox366642315/main.go:4 +0x80
注意main.go:4指示文件名和行號(hào)。
在您的示例中,程序沒有恐慌,而是選擇調(diào)用(我猜)os.Exit(1)或log.Fatal("error message")(調(diào)用os.Exit(1))?;蛘?,恐慌只是從調(diào)用函數(shù)中恢復(fù)。不幸的是,如果您不是代碼的作者,則對(duì)此無能為力。
- 3 回答
- 0 關(guān)注
- 207 瀏覽
添加回答
舉報(bào)