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 do, as it's not relevant to the logic of your own application. >
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"; > Given that you know exactly which function you called - and individual > functions > should be of small size - then if you look in the source of that function, the > point which decides and returns error X is generally obvious. Not in the case that I posted. > > > Same again: "where it was decided" means the author of stdlib would have to > generate the appropriate logs. > Indeed and they are best placed to do so. Unfortunately some instrumentation or disable flag may be needed in certain cases where atomicity is required. > > > > I see that backwards. Every error should be printed along with it's > current > file > name and line and optionally returned for logical handling reasons. A > chain is > recorded and potentially thrown away for some performance reason > > > What chain is "recorded and thrown away"? The only chain you have is the > function call chain. I meant a log/print chain if kept in memory for better performance. A flag not to record would be more accurate, I guess. Merely asking a question whether I have missed an implementation, not the details of a new implementaion. > > > What I would like is the line number close to the logic that decided an > error > occurred printed by default. > > > Once again, it sounds like you're saying you want stdlib to be instrumented. > This is not something which can be done mechanically, it would have to be > added > manually. It would make me happy for sure. There seems to be a lot of error handling that isn't of much use or is more opaque than it should be. 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. 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? 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. Despite trying to understand why people say they love interfaces. I hate them. e.g. I don't see the point of the private key tls interface when individual functions for each type are run anyway. Seems like abstract magic for no reason. I guess I am missing something there, if not here. I don't buy the API simplification argument...so far. Salt in this wound, I guess. Oh well. -- 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/9fdf9f36-a458-e4d0-806d-2af15962a67b%40gmail.com.
