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 redirected. In C I would
use __LINE__.
> I think the best you could get is the line number of B. And that's
> not very useful.
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 require stdlib
support, obv.
>
> Your own code presumably looks something like this:
>
> foo, err := library.Bar(baz)
> if err {
> ...
> }
>
> This means you already know exactly which function you're calling; the error
> must have "come from" somewhere in that function. (Of course, that function
> may
> have used the results from other functions before deciding to return an error)
>
> There are only a fixed number of return points from library.Bar - quite
> possible
> only one. Would it really help much to know which "return" statement was
> used?
I would want the log.Print with line to be near to where it was decided an error
occurred, not where it was decided an error should be returned.
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 but by default
you can run your program and grep the errors in the case of a huge chain but
otherwise have verbose information by default!
You shouldn't have to dig? Perhaps I am missing something?
Rather than reverseproxy.go:445, message from different file.
You would also get verify.go:??? possibly different message.
What I would like is the line number close to the logic that decided an error
occurred printed by default.
I print *and* return errors immediately? otherwise it is a logical decision that
may or may not still be printed?
--
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/35eadc4b-18c3-3888-9779-b0733295070a%40gmail.com.
