3 ms·

One thing I've never understood is why stack traces don't, at a bare minimum, contain the values of the arguments passed to the function that threw the exceptio

One thing I've never understood is why stack traces don't, at a bare minimum, contain the values of the arguments passed to the function that threw the exception. That would be immensely helpful for reproducing the error. Even better would be including the current values of any local variables introduced within the function, and any global variables referenced within the function.

robinson-wall 5y ago
This could be very dangerous, depending where an exception happened. Variables can contain critical secrets, like your TLS keys or a user's password and if your stack trace printer isn't aware of what should be redacted now you've got that in your logs.
- zanecodes 5y ago
  Agreed, but this would help force developers to deal with treating secrets with the care they should have been treating them with all along, in my opinion. PowerShell's [SecureString] type is something of a step in the right direction, although its execution is lacking in some respects. In any case, stack traces should _always_ be treated as secrets.
  - deleted 5y ago
    [deleted]
yongjik 5y ago
That would require each argument be printable (i.e., has a function that prints its contents in a human-readable format), which is not always a given. Also, trying to print an object may cause another exception. (Imagine what will happen if you have a linked list, and a printer function that follows the links and print all nodes, but now the list is circular.)
- zanecodes 5y ago
  That's a good point. I would also like very much if languages included a sensible and useful default implementation of toString() or the equivalent for all types (e.g. print all the object's private & public property names & values, recursively, stopping if cycles are found). Of course, this is probably only remotely feasible in languages that can guarantee that toString() won't have any side effects.
  - gizmo686 5y ago
    You need "side effects" to include memory allocation, seg faults, and "significant" amount of computation time (including never terminating). Worse, you need these properties when the program is known to be in an error state. For a general purpose programming language this means that your toString cannot be a normal function.
    - zanecodes 5y ago
      Also good points, I suppose the printing mechanism couldn't use the type's implementation of toString() and would instead have to use an implementation built into the runtime. Still, even being able to see just the raw bytes would be better than nothing in a lot of cases.
slaymaker1907 5y ago
You can sort of do this by taking a dump of the thread/process. Just print out the location of the dump to the log (main downside being you need a debugger to analyze these files).
Doxin 5y ago
pytest stack traces include function arguments for select stack traces. It's stupendously convenient, but it does make the stack traces rather verbose at times.

robinson-wall 5y ago

This could be very dangerous, depending where an exception happened. Variables can contain critical secrets, like your TLS keys or a user's password and if your stack trace printer isn't aware of what should be redacted now you've got that in your logs.

zanecodes 5y ago
Agreed, but this would help force developers to deal with treating secrets with the care they should have been treating them with all along, in my opinion. PowerShell's [SecureString] type is something of a step in the right direction, although its execution is lacking in some respects. In any case, stack traces should _always_ be treated as secrets.
- deleted 5y ago
  [deleted]

yongjik 5y ago

That would require each argument be printable (i.e., has a function that prints its contents in a human-readable format), which is not always a given. Also, trying to print an object may cause another exception. (Imagine what will happen if you have a linked list, and a printer function that follows the links and print all nodes, but now the list is circular.)

zanecodes 5y ago
That's a good point. I would also like very much if languages included a sensible and useful default implementation of toString() or the equivalent for all types (e.g. print all the object's private & public property names & values, recursively, stopping if cycles are found). Of course, this is probably only remotely feasible in languages that can guarantee that toString() won't have any side effects.
- gizmo686 5y ago
  You need "side effects" to include memory allocation, seg faults, and "significant" amount of computation time (including never terminating). Worse, you need these properties when the program is known to be in an error state. For a general purpose programming language this means that your toString cannot be a normal function.
  - zanecodes 5y ago
    Also good points, I suppose the printing mechanism couldn't use the type's implementation of toString() and would instead have to use an implementation built into the runtime. Still, even being able to see just the raw bytes would be better than nothing in a lot of cases.

slaymaker1907 5y ago

You can sort of do this by taking a dump of the thread/process. Just print out the location of the dump to the log (main downside being you need a debugger to analyze these files).

Doxin 5y ago

pytest stack traces include function arguments for select stack traces. It's stupendously convenient, but it does make the stack traces rather verbose at times.