Axel, thanks for the reply.
As I already replied to Tomas, I am not looking for improvements in this particular case where I need to call an SQL database. An no, I dont want to wrap all function I use into something which collects the errors for me. Let's say you want to log & panic & exit after any error. How do you do that, without putting code after each statement or wrapping? You can't. And that's why I am proposing to be a little bit open to new ideas. Every modern language I know of has some sort of try...catch construct. Martin On Monday, September 4, 2017 at 10:57:51 PM UTC+2, Axel Wagner wrote: > > See, e.g. here > <https://groups.google.com/d/topic/golang-nuts/ROr5jveMQvg/discussion> or > here > <https://groups.google.com/d/topic/golang-nuts/68J-mLCC1JI/discussion> for > previous discussions of very similar (even mostly identical) proposals. > > What I always dislike about these kinds of proposals is, that they are > encouraging not handling errors, but instead just passing them up-stack. In > general, all of the sites where you are checking for errors will signify > different error conditions, that should be communicated differently > upstream. For example: > > db.Prepare("INSERT INTO userinfo(username, departname, created) > values(?,?,?)") > -> This could fail for basically two reasons: Either communication with > your database somehow failed (e.g. a broken network connection), in which > case you want to return the equivalent of an HTTP 503 error, or the syntax > of your statement is wrong, in which case I'd argue panic'ing would be the > correct thing - at the very least, returning the equivalent of a 500. > > stmt.Exec("astaxie", "研发部门", "2012-12-09") > -> Either a 503. Or 400, 403, 409… > > res.LastInsertId() > -> 500 or 501? > > The issue is, that by simply checking for nil and passing it along, you > are *not handling your error*. Different error conditions require different > error handling and what the correct error handling is, depends heavily on > the application. An ENODIR error in one line of code can signify a totally > different error condition than the same error two lines later. So all of > these proposals are born out of an exception-style idea of how error > handling is supposed to work; deep within the call stack something goes > wrong and that something is then just bubbled up to be someone else's > problem. Good error handling just can't be well abbreviated in this way - > at least not generically. It's too application-specific for that. > > On Mon, Sep 4, 2017 at 8:27 PM, <marti...@programmfabrik.de <javascript:>> > wrote: > >> 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. >> > > A better take-away from that blog post would have been, to orient yourself > around the example of a writer given. You could, for example, provide a > one-time abstraction that wraps *sql.DB and collects the error. I'd agree > that the sql package tends to not be amazing for that, because of its set > of interdependent types, it is still possible. For example, with this > <https://play.golang.org/p/kdgBUqWeR->, you could write > > d := &errDB{db: d} > stmt := d.Prepare("INSERT INTO…") > res := stmt.Exec(…) > id := res.LastInsertId() > stmt := d.Prepare("UPDATE…") > res := stmt.Exec(…, id) > affect := res.RowsAffected() > return d.err > > Now… this isn't really nice either (see above. sql isn't really > well-designed for this. You'd probably try and implement a driver for this, > but sql doesn't make that easy either). And it's a bad idea for all the > same reasons the watch-proposal isn't a great idea here. But it illustrates > a far more effective take-away from that blog post. > > >> >> 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...@googlegroups.com <javascript:>. >> For more options, visit https://groups.google.com/d/optout. >> > > -- 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.
