Should error messages be reversed?

I find that every time I get an error message in (VScode) Julia, I have to scroll up to the top and then read top down. The first many lines of what is visible are generally not useful at all. This is particularly bad with VSCodeServer since there are many additional lines to scroll past. The error is more-or-less always in a line of user code, so it makes sense for that to be visible first.

Python trace backs are easier to read since the line that triggered the error is immediately visible, and I scroll up for more context.

Matlab error messages are typically concise and line triggering is discernible without scrolling.

From what I can gather of Rust, you can also see the line that caused an error without scrolling.

99% of the time I reach for the mouse when developing Julia is to scroll error messages to the top and read down.

It would seem a lot more ergonomic and friendly if we simply reversed the order of these error messages to read from bottom to top.

Related: https://github.com/JunoLab/Atom.jl/pull/98

9 Likes

The thing that’s a little weird about this is that REPLs kind of force people to read bottom to top. I think our current behavior is probably better for a program run from command line, but worse for repl development. One solution would be to have the REPL (instead of the language) reverse this.

Slightly related is that IMO the colors 1.6 adds to stack traces help with this a lot.

1 Like

On the contrary, I’ve always found Python’s tracebacks to be counter-intuitive. The Julia REPL is printing the stacktrace—in other words, the stack of function calls. The most recent call should be on top of the stack, and should therefore be printed at the top.

Another reason Python’s tracebacks are counter-intuitive is because I always read text from top to bottom. Python error messages are the only time I’m forced to read upwards.

7 Likes

I think vscode.jl should filter out the part related to vscodeserver, such that the output looks like in the REPL, that would already help a bit.

I really like the order and detail Julia has. I can usually easily track it down to my own call (maybe [9] or something down the lines) and fix that.

You’re right scrolling might be annoying, but Matlab does not give you the trace, so you have to do more to find the way down.

Maybe in an embedded REPL like in VS code something like a collapsed error message stack trace that you can expand would be helpful?

there is an open issue for this

3 Likes

Just to add a data point: Ruby printed stack-traces the same way as Julia for most of its existence, but has recently changed and adopted the Python bottom-to-top format.

I also agree that, when it comes to tooling/IDEs/editors, order shouldn’t really matter so long as the format is consistent and well specified. Then it is up to the tooling how it wants to parse and present the trace.

So what are the most common use cases where a Julia user would be likely to encounter a stack trace without a tool to help make sense of it? CLI scripts and the REPL seem like the most obvious answers, and in both cases it seems like presenting the most relevant lines from a stack trace directly to where the user’s focus lies (at the blinking cursor at the bottom of the screen) makes the most sense.

1 Like

Completely agree. Here’s an illustration of the point (code here, with top two showing status quo, and bottom one showing how it might look if flipped. I think the latter is clearly the better UX


Versus here’s the proposed reversal:

Edit: note that the same problem occurs when running from command line as julia temp.jl, in fact if anything it’s slightly worse as have to scroll up an additional 5 lines:

4 Likes