3 ms·
you think it's "smart" to encourage a large fraction of function calls to have if err != nil { return nil, err } after it? really? you don't think i
by bananapub 3y ago
you think it's "smart" to encourage a large fraction of function calls to have
if err != nil {
return nil, err
}
after it? really? you don't think it's just a very simple way to do it without having to do a lot of work in the language? and then make everyone use a linter to avoid bugs? oh and you can't always literally do 'return nil, err' because strings have to be ""?
it's certainly defensible as a minimalist approach, claiming it's actually good or smart or ideal is a pretty weird take.
- righthand 3y agoYou think it’s “a lot of work” to write an if statement? Any of the proposed variations have shown to be either different syntax (weak valueless change) or would allow people to ignore handling errors. You can’t always return nil? is that a complaint that you are required to do things differently for data types that require it inside of a complaint about doing things the same? It’s not a weird take, things have tradeoffs, this is a tradeoff of using Go.
- unscaled 3y agoIt's not a lot of work, you can just let the IDE spew it off for you and feel like a certified J2EE programmer circa 2003 who lets the IDE write everything for them. But yeah, writing code is not the problem. Reading the code is. I think having 60% of your lines of code being: if err != nil { return err } Does make the code a tad bit less readable.
- righthand 3y agoSo then it’s less readable because you have to process a simple error return? I won’t even comment on the 60% of code is error handling, that sounds like code that needs refactoring.
- yencabulator 3y agoThat's not what is encouraged. What is encouraged is actually handling the error, and adding information about the operation, to it.