3 ms·
#3 (too easy to ignore errors) and #6 (hard code generation) do not seem to be either A or B.
by junke 10y ago
#3 (too easy to ignore errors) and #6 (hard code generation) do not seem to be either A or B.
- pawadu 10y agoregarding #3, have you never seen code like this? try { stuff() } exception(Exception e) { } I would consider complaint #6 a B.
- junke 10y agoThis has nothing to do with the matter at hand. Explicitly ignoring errors is a feature that you sometimes need. The equivalent in Go would be to write: _ := db.Exec("DELTE FROM item WHERE id = 2") ... which could be written for bad reasons too, like in Java. However, nothing prevents from writing: db.Exec("DELTE FROM item WHERE id = 2") ... which would be like: stuff() Both of those could be written either intentionally or by error, maybe because someone did not read the documentation correctly. However with exceptions, even if the exception is not handled, at least it is caught. So Go by design does not use exceptions, which is respectable choice. However, it is supposed to be different from C by making it hard to ignore errors. And the example from #3 is the absolute contradiction of that philosophy. I'd expect all return values to be checked for usage. Go could take example from Ada in that regard. ----- For #6, what would be the solutions to OP's example problems?
- pawadu 10y agoHmmm, you are correct, it is easy to ignore these types of errors. I guess I should have read the article more carefully