On Friday, 10 April 2020 15:39:53 UTC+1, Kevin Chadwick wrote: > > We should be wanting more eyes on code. Also it potentially is and was of > some > use, in the case of:tls Example "VerifyPeerCertificate > > "https://golang.org/pkg/crypto/tls/#example_Config_verifyPeerCertificate"; > > 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. 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). > So I assume that the error pkg is just to please the dynamic side to the > language (tag on an extra error, rather than multiple specific returns), > yes? > There's the *error* interface, and there's the *errors* package. https://blog.golang.org/error-handling-and-go You are free to return a range of distinct concrete error types if you wish, to indicate different errors, and/or to carry additional information. For some APIs it would be good design to do this, where the caller needs to take different action based on different errors. errors.New() <https://golang.org/pkg/errors/#New> is just a short-cut for returning a simple error which needs nothing more than a text description. In python it would be like: raise RuntimeError("message"). And sometimes, this is all you need. > Maybe to avoid type pain? I love Go and can live with type handling but > the > dynamic side (interfaces etc.) is the side of the language that I disklike > significantly...so far. I think you'll get to like it. Interfaces allow you to have limited, controlled polymorphism where required. Although I spend a lot of time with dynamic languages like python, the thing I dislike most is that when I look at code like def foo(v): v.bar() I have no idea either what type v is, or where method bar() is defined: every method call is polymorphic. In go, the function being called is normally clear from the type of the variable (the awkward case being baz := foo(), which makes me go look at the return signature of foo() before I know the type of baz) In those limited cases where you *need* polymorphism, go provides it via interfaces, since it doesn't have generics or sum types (yet). And abstractions like io.Reader are very powerful. > I don't see the point of the private key tls > interface when individual functions for each type are run anyway. You mean https://golang.org/pkg/crypto/#PrivateKey ? I'm not really familiar with that API surface. It looks like this is performing the role of a (void *) in C - passing an arbitrary blob of data - and I expect there's some other part of the API where you need to pass in both an algorithm and (separately) a key. Again, without generics it's hard to make such things type-safe. -- 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/30147f31-16e2-4508-8009-e43d676a3a62%40googlegroups.com.
