When an error occurs, stacktraces are get printed in the same order as the stack unwinds. This is the opposite of Python’s behavior and makes it so I always need to scroll up to see what caused the error. Is there a way of reversing this order?
2 Likes
I don’t think it is possible to customize this at the moment at the user level.
That said, the current printing mechanism is pretty good about reducing/compressing repeated information, eg at most BIG_STACKTRACE_SIZE (currently 50) stack frames are printed, so it should fit on most screens.
You may also want to check out 1.6/master, stack trace printing has improved a lot.
2 Likes
It has been discussed many times (see e.g. https://github.com/JuliaLang/julia/pull/18228#issue-82605698). Other debuggers (like GDB) prints them in the same order as Julia. I would prefer the opposite order than the current one (especially now when we print some extra stuff so the number of lines are longer) but perhaps not to the extent where there is a toggle and every stacktrace you read from someone else might be in either order.
6 Likes
Yes, the recent improvements are indeed very nice! Unfortunately with lots of parametric types the signatures still get really, long really fast. I’m not necessarily looking for a solution for all cases, just a way of customizing it for my needs (doesn’t need to be anything user-level, apparently in Julia I can just recompile stuff in Base). What does BIG_STACKTRACE_SIZE do exactly? I’ve tried to reduce it but the printout appears identical.
First off thanks for your work (and the work of others) on cleaning up the traces. I can see how having a flag might make things confusing, that being said different languages already print differently so the confusion is really only avoid if you only program in 1 language! I ended up just adding a call to reverse! in show_backtrace and that works well enough for me.
Agreed. This is being discussed.
3 Likes
if we are taking a poll, I would have to vote for reversing the order also.
This would be especially useful when things in PyPlot fail because you get a LOT of python related messages before getting to the Julia errors.
Generally though the stack traces and error messages aren’t too difficult to decipher. I find that they even point out subtle things (like missing ‘)’) clearly.
The absolute hardest error for me to debug in an extra “end” statement. That really throws a spanner in the works
edit: LOL. I just realized, a LOT of python related errors before the Julia errors mean the current order would be better. I need another cup of 
To voice the opposing point of view, I always found Python’s stacktraces to be very confusing. It’s a stack, so the most recent call should be on top of the stack, right?
3 Likes
Yes, but we also draw trees with their root at the top of the page 
1 Like
You can just redefine the relevant methods in your startup.jl. This is technically type piracy, but since it’s just your environment, it should be harmless.
It reduces the length. See the code.
FWIW, I think that the order of stack traces is a topic about which reasonable people can have different opinions — there is no “natural” order. Consistency is more important, so that stack traces pasted in here and other forums are easy to interpret for others.
Because of this, I am not sure that making all aspects customizable is a good strategy; but there are certainly improvements that can be made.
1 Like