4 ms·
errors.Is only works if you have an actual ErrorType which you have to manually hunt down only to find it's a fmt.Errof and it doesn't work.
by the_gipsy 4y ago
errors.Is only works if you have an actual ErrorType which you have to manually hunt down only to find it's a fmt.Errof and it doesn't work.
- c7DJTLrn 4y agoIt'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.