3 ms·
Errors do not only happen because of code defects, they are often a response to bad data. And even if there were fewer defects, that could be because of other f
by MattPalmer1086 2y ago
Errors do not only happen because of code defects, they are often a response to bad data. And even if there were fewer defects, that could be because of other features of Go, not the error handling.
So that doesn't seem like a good metric to determine if Go's error handling is "better" (in some dimension) than other techniques.
- CharlieDigital 2y agoBad data isn't unique to Go; let's assume bad data is an external constant. If Go is a superior programming language -- error handling or not -- it should be easy to find the statistical evidence. Otherwise, you just prefer green crayons; please, by all means, go enjoy your green crayons. Go's error handling isn't any better or worse; it's just objectively way more verbose. With what benefit? If you wish to claim one beyond your subjective vibes, please by all means prove it with evidence.
- MattPalmer1086 2y agoThe topic was not determining which language has fewer defects. It was specifically about whether the error handling aspect is better. I'm not claiming any benefit by the way of Go's error handling. I've never even used Go. Just pointing out that measuring defects is not a good way to determine whether it is or isn't.
- CharlieDigital 2y ago> It was specifically about whether the error handling aspect is better. If it's better, how? Can you prove it? Does it lead to lower defect rates? Lower time to debug? Less runtime errors? How is it better other than your preference of green crayons?
- MattPalmer1086 2y agoAs I said before, I've never used Go. I have no opinions about its error handling, or green crayons for that matter. Measuring defect rates against another language will not tell you whether the error handling is better or worse than the other language either.