I forgot (again) to say that in this case the error would just be returned.
In other words, `watch err` would just check if `err != nil` and then return. The other cases (test, main) would be as explained earlier (FailNow(), Exit(1)) On Tuesday, September 5, 2017 at 10:14:16 AM UTC+10, Dorival Pedroso wrote: > > Hi, the `watch err` could also work in "APIs" that already return "error". > > For instance: > package myapi > > func First() (err error) { > watch err > err = internalFunction(1,2,3) > err = internalFunction(3,2,1) > err = internalFunction(1,3,2) > } > > > > > On Tuesday, September 5, 2017 at 4:27:20 AM UTC+10, > marti...@programmfabrik.de wrote: >> >> Hi guys, >> >> at first I though I really like the idea of how Go deals with error >> management and handling, but the more Go code I look at or try to program, >> the more I get scared about checking errors every second line in every >> given block of code. >> >> Take a look at this example here from "Build Web Application with Golang": >> >> // insert >> stmt, err := db.Prepare("INSERT INTO userinfo(username, departname, created) >> values(?,?,?)") >> if err != nil { >> // handle error >> } >> res, err := stmt.Exec("astaxie", "研发部门", "2012-12-09") >> if err != nil { >> // handle error >> } >> id, err := res.LastInsertId() >> if err != nil { >> // handle error >> } >> fmt.Println(id) >> // update >> stmt, err = db.Prepare("update userinfo set username=? where uid=?") >> if err != nil { >> // handle error >> } >> res, err = stmt.Exec("astaxieupdate", id) >> if err != nil { >> // handle error >> } >> affect, err := res.RowsAffected() >> if err != nil { >> // handle error >> } >> >> >> Seriously? And yes, I have read >> https://blog.golang.org/errors-are-values... >> >> The best case reduction I found is: >> >> ... >> res, err = stmt.Exec("astaxieupdate", id) >> checkError(err) >> ... >> >> Still, I need this after each line of calling a function which may return >> an error. >> >> I bet this is not pleasant to do in larger code bases and it also takes >> away focus from what is actually happening. >> >> 50-80% of all lines of code in my example deal with error handling? >> >> This is not good. Seriously. >> >> And don't get me wrong, there is a lot of things I really like, love and >> adore about Go, but catching errors needs an improved syntax! >> >> And I am not proposing try...catch here. >> >> How about introducing a new piece of syntax >> >> "watch if .... " >> >> which tells the compiler to watch out for changes in a given SimpleStmt >> >> The same code as above would look like this: >> >> var err Error >> >> watch if err != nil { >> // handle error(s) >> } >> >> // insert >> stmt, err := db.Prepare("INSERT INTO userinfo(username, departname, >> created) values(?,?,?)") >> res, err := stmt.Exec("astaxie", "研发部门", "2012-12-09") >> id, err := res.LastInsertId() >> fmt.Println(id) >> >> // update >> stmt, err = db.Prepare("update userinfo set username=? where uid=?") >> res, err = stmt.Exec("astaxieupdate", id) >> affect, err := res.RowsAffected() >> >> >> - The "watch if" would be executed after each assignment of any of >> the variables used in SimpleStmt of the statement. >> - Multiple "watch if" would be executed in order or appearance >> - The "watch if" could be used like "defer..." inside functions >> - The "watch if" would work in its full scope of the watched variables >> >> I am not a language expert, so may be there is a saner way of expression >> what I want to achieve. >> >> But bottom line is, there should by an easier to read and write way to >> deal with errors in Go. >> >> >> Martin >> >> >> >> >> >> -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.