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 certifi
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 afr
On 2020-04-10 14:05, Brian Candler wrote:
> But why do you want this? A library you called already returns a descriptive
> error of what went wrong. The library is a black box. If you want to open
> the
> black box to learn how it works, that's fine, but not something most people
> want
> to d
On Friday, 10 April 2020 12:22:30 UTC+1, Kevin Chadwick wrote:
>
>
> I disagree, if baz threw and error then it itself should have printed an
> error
> before returning, saving me minutes of grepping. The calling function may
> also
> print a more pertinent logical error. I realise this would r
On 2020-04-09 10:17, Brian Candler wrote:
Sorry, for some reason I missed this reply.
> However without modifying the code (or changing the
> language, so that every variable value remembers the line number where it was
> last set),
The Log package does that for you. This output can be redirect
Do you mean the line number *in the library function* ??
In general, I think that's an impossible problem. Consider a somewhat
convoluted example of a library function:
func Bar(...) {
...
if xyz() {
blah = true
}
if abc() {
baz = false
}
...
if blah
