On 2020-04-10 22:20, Brian Candler wrote: > > > I'm afraid I don't see the problem. > > That's an example of using the TLS API. In this API, the user passes a > callback > function to be called at a certain point in the TLS exchange. *Your* function > returns an err to say whether the certificate is acceptable or not. >
That isn't true. It comes from logf function of reverseproxy.go. Grepping tracks it down to a function with just switch cases on output strings. Grepping further for a variable eventually leads you to the logic. With all that abstraction. I assumed something useful must be going on but I still struggle to see it. I find that the error interface creates opaqueness not transparency and maybe I needed to be brought into the light of it's beauty. I guess not. Now I am wondering if those that thought if err != nil was too verbose have already caused a lack of clarity. > All that the caller of this function (i.e. the TLS library) cares about is > whether the certificate is acceptable or not, so as whether to continue with > TLS > or abort. > > I assume that you are saying that the only way of garnering the first > source of > the error is from reading lots of code? Which was my question. Am I > missing a > way to get this. > > > Well, I'm saying that a library tells you whether there was an error or not, > and > what the error *was*. I don't care *where* in the library code this decision > was made. It's not my concern, unless I don't trust the library to do it's > job > properly (in which case, the problems are more serious). I completely disagree for many reasons! You may need more information than the error provides. The documentation may be lacking or take longer to interpret than the code. You may want to see if you can adapt the library or code to a particular problem and be sure it's security is intact. It would increase the likelihood of patches or improvements to be made and bugs be spotted. I never said there was a problem. It just doesn't seem very helpful. I'm not a spoilt brat. I am thankful for the stdlib. I was just in wonder. Thank You for your time. -- 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/d068375f-aa92-421b-1e6b-7944bb5acec6%40gmail.com.
