3 ms·
Due to the nature of my work I'm often in a position to write, deploy and then maintain systems that are running my code and generally have to play the part of
by akira2501 3y ago
Due to the nature of my work I'm often in a position to write, deploy and then maintain systems that are running my code and generally have to play the part of top tier support for the entire stack.
The more that this has become my reality, the more I care about actually producing worthwhile errors. I'm not at all bothered that 70% of my code is error case management with some liberal sprinklings of context into those values.
At this point, I see straight through them in my code, to the point where I'm actually going to be confronted with an error, bug or emergent system case and I'm going to be exceptionally pleased that I put so much effort into actually managing these errors correctly and not just punting them up through a common and often cryptic common error handler case with most of the useful context about the detailed error environment now missing.
- beautron 3y agoThis is exactly how I feel about Go error handling (which I prefer to other languages). Error checks become a syntactic formalism that are easy and quick to type, easy and quick for the eye to scan, but have just enough presence to make sure you think through your error situation whenever and wherever you need to. Go gives me a confidence in my code's error handling that is harder to get in other languages I've used, where the error situation is typically muddier.