4 ms·

As a not-yet-experienced Go programmer, I have to say it'd make it way more palatable if the reference to the error in my code could be somehow extracted and di

As a not-yet-experienced Go programmer, I have to say it'd make it way more palatable if the reference to the error in my code could be somehow extracted and displayed in a more obvious fashion. I've had panic happen in Go code before (most of the time when trying to read the body of a http response that happened to be nil for whatever reason) and I was kind of lost in a trace of errors happening deeper in the standard library that I mostly didn't care about at first sight (until a few lines down, I could find a reference to my own program). That being said, Go is still a pretty good language when it comes to tooling and error handling / reporting.

mellett68 9y ago
Really this is my main complaint with most languages/tools when it comes to runtime errors. This is especially painful when you introduce frameworks and things that create so much misdirection that the call stack can be enormous.
laumars 9y ago
To offer a counterargument, I've always considered Go's panics to be pretty readable because you can read the top line to get the error and then one of the next lines down (I forget which but after a while it tends to stand out) to see the line where the error was raised. The rest of the stack is if you need to trace the error back through the calling routines (I rarely need to do this but it's useful if the panic isn't being raised by your own code). Granted things get a little more tricky when you start multiplying the number of concurrent goroutines. I've sometimes ended up with several terminal screens full text. But so long as you can find the start of the panic output then you can generally find what you want without too much difficulty.
tomsmeding 9y ago
Have you ever looked at typical template compiler errors in C++? The same problem occurs, I suppose, but then much worse. I regularly have multiple screens of text where your own single line of code is hidden like a needle in a haystack. Clang seems to do this _slightly_ better than gcc, but it's both bad.

mellett68 9y ago

Really this is my main complaint with most languages/tools when it comes to runtime errors. This is especially painful when you introduce frameworks and things that create so much misdirection that the call stack can be enormous.

laumars 9y ago

To offer a counterargument, I've always considered Go's panics to be pretty readable because you can read the top line to get the error and then one of the next lines down (I forget which but after a while it tends to stand out) to see the line where the error was raised. The rest of the stack is if you need to trace the error back through the calling routines (I rarely need to do this but it's useful if the panic isn't being raised by your own code). Granted things get a little more tricky when you start multiplying the number of concurrent goroutines. I've sometimes ended up with several terminal screens full text. But so long as you can find the start of the panic output then you can generally find what you want without too much difficulty.

tomsmeding 9y ago

Have you ever looked at typical template compiler errors in C++? The same problem occurs, I suppose, but then much worse. I regularly have multiple screens of text where your own single line of code is hidden like a needle in a haystack. Clang seems to do this _slightly_ better than gcc, but it's both bad.