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 require stdlib
> support, obv.
>
Exactly: someone would need to modify stdlib to generate additional
debugging information at whatever the author decides are "interesting"
decision points.
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.
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.
If the error is a result of a system call, you can run your program under
strace / dtruss etc to get visibility of it.
If you think the library itself is misbehaving, you can run it under a
debugger.
>
> >
> > 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.
>
Same again: "where it was decided" means the author of stdlib would have to
generate the appropriate logs.
>
> 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. The stdlib function at the tip of the chain then
returns, and its frame is popped off the stack. But even if it wasn't, all
it would record is the values of its local variables just before it
returned. It does not record what control path was taken through that
function. With some changes it might be possible to record the program
counter just before it returned (i.e. the exit point), but you already said
you didn't want this.
> 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.
--
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/60365359-1e25-4c2f-a4c8-76c9e577cd16%40googlegroups.com.
