4 ms·
It's rarely the case that you need to know exactly where the error originated. You just need to check if the error wraps a network error or EOF error for exampl
by c7DJTLrn 4y ago
It's rarely the case that you need to know exactly where the error originated. You just need to check if the error wraps a network error or EOF error for example.
If you do need to know specifically what the error was then the API provides public error types.
- the_gipsy 4y agoNo, "the API" doesn't. I have encountered many libs that just do fmt.Errof, and just like that application code does too. So go doesn't do error handling well at all. Give your stdlib a stringly error maker, that's what will creep in everywhere. It doesn't matter if there is a section for creating (somewhat) typed errors - half of go code doesn't bother and together with the poor type system you can't even be sure which type of error you got.
- nindalf 4y agoI wouldn’t bother replying further. Clearly they’ve got a very strong opinion on this. Multiple people have pointed out the issues with their line of thought but they continue to persist. They’ll understand if they reflect on it, maybe.
- the_gipsy 4y agoYea. Actually, they should get hands on with error handling other than go or your run of the mill exceptions.