Re:Go 1.2
by nemothekid on Friday November 29, 2013 @05:09PM
(#6821213)
I agree with the panic sentiment. I almost never know when to actually use panic or to just return an error code. My guess is the reason panic is never used is because its "bad go" for a panic to leave your library/package.
Generally speaking, you ought to use error instead of panic. The only time panic is appropriate is when the program really ought to just crash.
For example, I'm writing a small program to update a database. If the DB connection can't be opened, the program can't do anything useful, so it can just exit with an error.
Any library should just use error.
Why isn't lack of DB connection a panic condition?
Why isn't lack of DB connection a panic condition?
It is a panic condition... I could have chosen my words better. That's what I meant by the program exiting.
I would also prefer that the type system could catch null pointer exceptions, but most languages don't give this guarantee, so it's not that big of a deal.
Another thing people gripe about is that exceptions (panic) is almost never used, and that most functions return error codes. I've yet to decide what I think about this issue, but sometimes it does feel like Go went for "NO EXCEPTIONS!" and then figured out they needed exceptions anyway and added panic/recover as an afterthought.
What I do love about Go though is the implicit interfaces, := assignment, forcing if and for to be followed by {}, no inheritance, concurrency and the non-forgiving compiler.