Discussion about error reporting in the REPL, should it be customizable?

[KristofferC]

TLDR: Error messages in the REPL can get very long and have low signal to noise ratio. Maybe there should be an option to determine how they are printed?

I don't know if this could be considered a "julep" but I think it would be good to have a discussion about the error messages we print. There are two main reasons that I think causes large error messages in Julia:

• Multiple dispatch encourages many methods with small bodies that for example just converts and argument and then calls another method of the same function. This leads to quite deep stack traces.
• Parameterization of types that might be arbitrarily nested leads to types that when printed in full detail can easily take > 50 characters.
• Inlined methods are now shown in the backtrace

The combination of the points above leads to backtraces that for me at least commonly look like this. While sometimes being good to have all the details i personally often get lost in this "Red Sea" looking for the line in my own code where the problem is.

I believe a one size fits all approach for printing errors is not going to work due to different demands in different situation so what is needed is to let the user have some control over the way the errors are printed. A few questions that naturally arises are:

• What options should there be? What should be default?
• How should these option flow through the showerror functions and the show function for a StackFrame? Could IOContext be used for that?
• How should the options be controlled. ENV variables? Some global state? This is related to the previous point.

Right now, I would say that the biggest source of noise are the types of the function arguments in the backtrace. I am almost never interested in them and if happen to be I could just go to the source location and look at them. Having an option to not print those would get a long way.

I have experimented a bit in a package that just rudely overwrites a few methods in Base so that you can set some options in https://github.com/KristofferC/ErrorMessages.jl.

Some other random suggestions / ideas:

• Instead of printing the whole error message in red, perhaps we can exploit a few more colors. Function definition in one color, arguments in another and the file location in another?
• Should the file information be printed on a separate indented line from the function definition?
• Should the backtrace actually be printed in reverse order so that the function on top of the stack is the one closest to the new prompt line. It is awkward when you have to scroll up to see where the error actually got thrown

Would be interesting to hear your ideas / comments. :)

cc @jakebolewski

[timholy]

Of the problems you list, the one I can unequivocally agree with is the difficulty of reading the types. But I don't have a great idea for how to print them without making the display longer in the vertical direction. About the only good idea I've had is that this would be solvable in an IDE where you can click-to-expand the type parameters. They start out compact ("folded") by default.

[mauro3]

👍 For me, only printing the actual error, the function names, and the line numbers in red would go a long way. Once I got the line-number it's easy to also see the file without it being printed in red, and it would also be easy to ignore the noise from the types. But keeping the types is probably good when further digging is necessary. I suspect adding more colors is not going to help much or any.

[Petr-Hlavenka]

What about writing the full error report into some error-log file and minimize the REPL output to just basic information (such as demonstrated in https://github.com/KristofferC/ErrorMessages.jl.)? So even if limited information is given on the REPL, one could still get the full info looking into the log file?

[KristofferC]

Perhaps but it can be annoying to go look in a log file. I still feel like in order for everyone to be happy it needs to be customizable and that you can rethrow the last error with new verbosity settings in case you want to examine it more carefully.

[Petr-Hlavenka]

Yes, it should be combination of both. You customize the REPL for your needs to get acceptable noise level. But then you face a rare bug in a day running monte-carlo simulation on parallel nodes and before you get the change to re-throw the last error it is already gone and you have no way to investigate it.

[StefanKarpinski]

I think the ideal experience would be interactive: we show information about the line that we actually think has the problem; if you want more detail, you click on it to see more detail. This is presumably possible in an environment like Juno, maybe in Jupyter, but very hard in a terminal. So maybe the last error could be bound, by default to err like ans is bound to the last normal answer value. Then you could get a summary of an error by default and do err to see more.

[KristofferC]

This is fixed now in my opinion.