CODEWITHSUNDEEP
go
Dani-Br
Dani-Br

Reputation: 2457

how to ignore returned error in GO

I have started learning Go today.
One thing that makes me crazy, it's the err returned parameter.

Let's assume I need to nest few functions. like this: 

return string(json.Marshal(MyData))

or more complex example: 

return func1(func2(func3(MyData)))

Is it really necessary to write: 

tmp1 , _ = func3(MyData)
tmp2 , _ = func2(tmp1)
tmp3 , _ = func1(tmp2)
return tmp3

That's annoying!
Is there any way to make the code looks cleaner?

Upvotes: 9

Views: 22694

Answers (4)

ioudas
ioudas

Reputation: 194

Took answer from ReyCharles, but made it generic so that you don't have to cast.

func IgnoreError[T any](val T, err error) T {
   return val
}

Upvotes: 1

okdewit
okdewit

Reputation: 2576

One possible abstraction pattern you will often see is to use a generic error handler.

This doesn't prevent you from having to deal with error values, but it does abstract the handling of errors away from the rest of your code.

Note that abstractions like these are considered "non-idiomatic" Go, the "pure" way is to explicitly handle errors in-place. This panic-driven alternative can still be very useful though, especially for quickly prototyping a script where you just want to dump all the errors in a console or logfile.

For reusable packages, I would stick to the verbose explicit way though, because others will expect error-producing functions to actually return error values, rather than using a panic-recover mechanism.

package main

import (
    utils
)

func main() {
    defer func() {
        utils.Handle(func(err error) {
            // Handle errors in a generic way, 
            // for example using println, or writing to http 
        })
    }()

    var result, err := someFragileFunction()
    Check(err)
}

package utils

func Check(err error) {
    if err != nil {
        panic(err)
    }
}

func Handle(handler func(err error))  {
    if r := recover(); r != nil {
        if err, ok := r.(error); ok {
            handler(err)
        } else {
            panic(r)
        }
    }
}

Upvotes: 2

Staven
Staven

Reputation: 3165

The real answer is: Don't.

Never just ignore the errors.

Seriously. The errors are there for a reason. If a function returns an error, it almost always means that it's possible, during the operation of your program, even if it's 100% bug-free, for the function to fail. And if it does, you don't usually want to just keep going as if nothing happened.

If you're absolutely sure that you're using a function in a way that ensures that it will never return a non-nil error (unless there's a bug in your program, and there always is), you might want to write a Must-style function like in the template package which panics with the returned error value.

Error handling is not noise. It's not clutter. It's not something you want to get rid of. If it looks like 50% of your program is error handling, that's because 50% of your program is, and should be, error handling.

Upvotes: -5

ReyCharles
ReyCharles

Reputation: 1792

It is possible to define a function to ignore errors, but Go's lack of generics make it so you'd have to use interface{} and typecasts all over the place, losing a lot of static guarantees from the typechecker in the process. It is extremely ugly. Don't do this.

func ignoreError(val interface {}, err error) interface {} {
    return val
}

At every call to ignoreError() you would have to make a type cast to the expected return type.

Playground example

Upvotes: 7

Related Questions