> The current approach of passing them through mostly untouched still allows the > application to make any decision it wants based on them - and that's where the > necessary information is anyway.
I like the approach with multi return far more than Darts try, catch etc. My first thought was that perhaps they shouldn't need a grep to find, but that is of course easier said than done, with so many builds. >> And even given Posix, you might have small variance in exact interpretation >> of certain error codes or constants, so it tends to be a good thing to make >> sure your operating system interprets them as you expect. In addition, many >> modern APIs live outside the umbrella of Posix, making things even more >> fluctuating in what you can expect. As a general rule, I tend to go with Alex >> suggestion: pack them away until they are needed and only use them with >> surgical precision. I don't actually need them logically, though I did a little when using TLS. The errors.Is is mainly to give a user a more friendly rectification message and the actual log message if a more information button, is clicked. I'm OK with testing and grepping for them though, actually. Especially with the stability that syscall.Errno brings. Regards, kc -- You received this message because you are subscribed to the Google Groups "golang-nuts" group. To unsubscribe from this group and stop receiving emails from it, send an email to golang-nuts+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/golang-nuts/7d2be321-26dd-b1bd-84cf-c1f4a5996d2e%40gmail.com.
