Hi,

Error management in Go is perfect!

But I like the idea of `watch` (may we drop the `if`?)

So, `watch` would work in the context of a function like `defer`. However, 
this would effectively become a `catcher` for errors (instead of `panics`) 
within the `defer` function, right?

Also, I think `watch` would effectively be a "conditioned defer".

Once, I've spent hours adding `if err != nil { ... }` elsewhere in my code. 
Lately, I've started using two auxiliary functions just for readability:

In tests, I use:
func status(tst *testing.T, err error) {
    if err != nil {
        tst.Errorf("ERROR: %v\n", err)
        tst.FailNow()
    }
}

func TestBessel01(tst *testing.T) {
    dat, err := ReadTable("data/as-9-bessel-integer-big.cmp")
    status(tst, err)
    ...
}

In "main functions", I use:
func status(err error) {
    if err != nil {
        io.Pf("ERROR: %v\n", err)
        os.Exit(1)
    }
}

I (try to) check the errors everywhere in the API and these "syntax sugars" 
are only required at the final stages ("test mode" or "main function").

So, `watch` could be something like:
func TestBessel01(tst *testing.T) {
    watch err error // the compiler could detect that we're on "test" mode 
and then return when err != nil
    dat, err := ReadTable("data/as-9-bessel-integer-big.cmp")
    err = ComputeWithData(dat)
    ...
    err = DoSomethingElse(dat)
    ...
}

In "main functions":
func main() {
    watch err error // the compiler would detect that we're on "main 
function" mode and then Exit(1)
    err := ComputeWithData(...)
}

The command `watch` could even be used for different purposes; e.g. when 
something that should be <nil> isn't.

Cheers.
D


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.

Reply via email to