> However complex error recovery is an anti pattern for Go.
Bit of snark from my side, but that's exactly what makes it less good of a fit for "industry purposes".
Go's error handling is possibly the worst out of any "modern" language, it basically copied C's errno which is not something you should have ever done.
This was exactly my experience when I first read about Go. I was so excited until I found they were repeating the c experience of check every bloody return value separately. That was the worst feature of c - why copy it
Because almost my definition you can't handle errors in the component, otherwise you would have a conditional and not an error.
E.g. if I do some IO like "make a copy of these files" and get an error/exception, it's only the caller or maybe even that caller's caller that can properly deal with this condition (e.g. to decide that we will skip the erroneous files or retry).
That's what all these accounting rules exist to stop. No, you can't pretend that equipment breaking doesn't happen. No, you need to account for fixing the roof etc.
Well, good thing you aren't drinking it then, because the complete lack of electrolytes would kill you far faster than the microplastics. Surely if they can chemically purify the water to chip-making standards they can filter out the microplastics (when they are done with it)? At least one can hope.
reply