4 ms·

I've come to disagree with the notion of stacks being attached to every error. And I say that having previously authored a library for attaching stacks to ever

I've come to disagree with the notion of stacks being attached to every error. And I say that having previously authored a library for attaching stacks to every error in golang, and having used it for several months in several projects. It's very useful for errors to say something about where they're from. It's possible to do that in more ways than simply having a line number -- I think we've all become a little to quick to be reliant on line numbers as the best, or even only way to tell that story; it just ain't so. Line numbers are great when you're in a development cycle on your own personal laptop, and the source checkout and one binary you're running are in lockstep. Line numbers become completely insufficient when you're debugging a large system, particularly if it has more than one version of a particular process. Quick, what's "Line 169" mean when it shows up in your logging bucket during a rolling blue/green deploy of your code to a >100 node cluster? Stack traces are just a slice of line numbers. They're not magical, and since it's not a given that line numbers provide all context necessary to trace something, it follows that stack traces don't necessarily provide all context necessary to trace something either.

sciurus 9y ago
Stack traces not providing enough context necessary to trace something is an argument for attaching, more information to errors, not less. Checking entries in my https://sentry.io https://sentry.io installation, for example, I see the exception, the stack trace, the server the error occurred on, the release it was running, the URL being accessed, the values of local variables, etc. Having all this is invaluable for understanding what went wrong.
ereyes01 9y ago
I agree, there's too much uncertainty with line numbers, especially in a changing codebase. A system I used to work on (in C) had the build system generate unique error codes for every unique error point. The codes were 64 bits and consisted of an eye-catcher prefix for easy identification in a hex dump (think it was 0xEEE7), 24 bits identifying the file, and the rest was the error code. Every build generated a map file for you to look up error codes quickly. To generate one of these errors, you called a macro with ugly magic code that generated the unique part of the code, and returned that, logged it in the trace, or whatever. The unique codes served us quite well in precisely identifying where they came from. It would be nice if Go and other languages somehow baked that in for us so you would have a user-friendly error message accompanied with the unique code for developers (which users can just easily ignore).
- heavenlyhash 9y ago
  Yes, similarly, I rather admire the way mysql for example has numeric error codes from a large and no-reuse-allowed table. The human readable string hints what's going on; the numeric code is pretty much guaranteed to find you a relevant hit in $search_engine_of_choice, and will be relevant to your version of the software even if a similar human-readable message is used in different ways in other versions. It seems to be a pretty large up-front organizational commitment, though, and also requires significant discipline to stick to; possible in mature products, but tricky in young rapid-iteration areas.

sciurus 9y ago

Stack traces not providing enough context necessary to trace something is an argument for attaching, more information to errors, not less. Checking entries in my https://sentry.io https://sentry.io installation, for example, I see the exception, the stack trace, the server the error occurred on, the release it was running, the URL being accessed, the values of local variables, etc. Having all this is invaluable for understanding what went wrong.

ereyes01 9y ago

I agree, there's too much uncertainty with line numbers, especially in a changing codebase. A system I used to work on (in C) had the build system generate unique error codes for every unique error point. The codes were 64 bits and consisted of an eye-catcher prefix for easy identification in a hex dump (think it was 0xEEE7), 24 bits identifying the file, and the rest was the error code. Every build generated a map file for you to look up error codes quickly. To generate one of these errors, you called a macro with ugly magic code that generated the unique part of the code, and returned that, logged it in the trace, or whatever. The unique codes served us quite well in precisely identifying where they came from. It would be nice if Go and other languages somehow baked that in for us so you would have a user-friendly error message accompanied with the unique code for developers (which users can just easily ignore).

heavenlyhash 9y ago
Yes, similarly, I rather admire the way mysql for example has numeric error codes from a large and no-reuse-allowed table. The human readable string hints what's going on; the numeric code is pretty much guaranteed to find you a relevant hit in $search_engine_of_choice, and will be relevant to your version of the software even if a similar human-readable message is used in different ways in other versions. It seems to be a pretty large up-front organizational commitment, though, and also requires significant discipline to stick to; possible in mature products, but tricky in young rapid-iteration areas.