# Stacktraces print backwards

**URL:** <https://discourse.julialang.org/t/stacktraces-print-backwards/47722>\
**Category:** General Usage\
**Tags:** question\
**Created:** [October 4, 2020, 2:01am UTC](https://discourse.julialang.org/t/stacktraces-print-backwards/47722 "2020-10-04T02:01:32Z")\
**Posts on this page:** 10\
**Page:** 1

<div class="post-metadata">

**Author:** ![Ginter](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ginter/32/9829_2.png) [@Ginter](https://discourse.julialang.org/u/Ginter)\
**Post date:** [October 4, 2020, 2:01am UTC](https://discourse.julialang.org/t/stacktraces-print-backwards/47722/1 "2020-10-04T02:01:32Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [October 4, 2020, 11:03am UTC](https://discourse.julialang.org/t/stacktraces-print-backwards/47722/2 "2020-10-04T11:03:43Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![kristoffer.carlsson](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/kristoffer.carlsson/32/22_2.png) [@kristoffer.carlsson](https://discourse.julialang.org/u/kristoffer.carlsson)\
**Post date:** [October 4, 2020, 12:18pm UTC](https://discourse.julialang.org/t/stacktraces-print-backwards/47722/3 "2020-10-04T12:18:24Z")

</div>

> [@Ginter](#):
>
> 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?

It has been discussed many times (see e.g. [https://github.com/JuliaLang/julia/pull/18228#issue-82605698](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.

---

<div class="post-metadata">

**Author:** ![Ginter](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ginter/32/9829_2.png) [@Ginter](https://discourse.julialang.org/u/Ginter)\
**Post date:** [October 4, 2020, 6:54pm UTC](https://discourse.julialang.org/t/stacktraces-print-backwards/47722/4 "2020-10-04T18:54:04Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![Ginter](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ginter/32/9829_2.png) [@Ginter](https://discourse.julialang.org/u/Ginter)\
**Post date:** [October 4, 2020, 7:02pm UTC](https://discourse.julialang.org/t/stacktraces-print-backwards/47722/5 "2020-10-04T19:02:56Z")

</div>

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.

---

<div class="post-metadata">

**Author:** ![tomerarnon](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tomerarnon/32/3170_2.png) [@tomerarnon](https://discourse.julialang.org/u/tomerarnon)\
**Post date:** [October 4, 2020, 7:10pm UTC](https://discourse.julialang.org/t/stacktraces-print-backwards/47722/6 "2020-10-04T19:10:51Z")

</div>

> [@Ginter](#):
>
> Unfortunately with lots of parametric types the signatures still get really, long really fast.

Agreed. [This is being discussed.](https://discourse.julialang.org/t/these-stack-traces-are-out-of-control/47162)

---

<div class="post-metadata">

**Author:** ![purplishrock](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/purplishrock/32/13451_2.png) [@purplishrock](https://discourse.julialang.org/u/purplishrock)\
**Post date:** [October 4, 2020, 7:15pm UTC](https://discourse.julialang.org/t/stacktraces-print-backwards/47722/7 "2020-10-04T19:15:26Z")

</div>

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 ☕

---

<div class="post-metadata">

**Author:** ![CameronBieganek](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/cameronbieganek/32/6915_2.png) [@CameronBieganek](https://discourse.julialang.org/u/CameronBieganek)\
**Post date:** [October 4, 2020, 11:15pm UTC](https://discourse.julialang.org/t/stacktraces-print-backwards/47722/8 "2020-10-04T23:15:04Z")

</div>

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?

---

<div class="post-metadata">

**Author:** ![Ginter](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/ginter/32/9829_2.png) [@Ginter](https://discourse.julialang.org/u/Ginter)\
**Post date:** [October 5, 2020, 5:33am UTC](https://discourse.julialang.org/t/stacktraces-print-backwards/47722/9 "2020-10-05T05:33:35Z")

</div>

Yes, but we also draw trees with their root at the top of the page 🙂

---

<div class="post-metadata">

**Author:** ![Tamas\_Papp](https://sea2.discourse-cdn.com/julialang/user_avatar/discourse.julialang.org/tamas_papp/32/25949_2.png) [@Tamas\_Papp](https://discourse.julialang.org/u/Tamas_Papp)\
**Post date:** [October 5, 2020, 6:39am UTC](https://discourse.julialang.org/t/stacktraces-print-backwards/47722/10 "2020-10-05T06:39:53Z")

</div>

> [@Ginter](#):
>
> I’m not necessarily looking for a solution for all cases, just a way of customizing it for my needs

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.

> [@Ginter](#):
>
> What does BIG\_STACKTRACE\_SIZE do exactly? I’ve tried to reduce it but the printout appears identical.

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.