Discussion on Julia Error System

[camilogarciabotero]

Hi,

Thanks again for working on Term. I know there is a lot of effort towards a 2.0 version which will improve Term in many fronts. You also might be aware of the JuliaSyntax project. I wanted to open this discussion to ask if Term v2.0 will be compatible with the JuliaSyntax as it will change some of the front-end error messages and logs

[FedeClaudi]

Hey,

No, I wasn't aware of JuliaSyntax, looks interesting. Currently Term replaces Base.showerror(er, bt) so if JuliaSyntax displays messages by interacting with that method it won't be compatible. I'd be interested in finding a way to make Term less disruptive of other workflows though, happy to hear recomendations.

[camilogarciabotero]

I don't really know how JuliaSyntax interacts with error displaying. Although there is already a PR that enables the JuliaSyntax option as the main parser, which might be useful to test compatibilities with Term. As far as I understand it will replace the current parser in the following minor versions (maybe 1.10). I've opened an issue (better feature idea) about some other projects that might intersect with Term and the JuliaSyntax way of displaying errors. Maybe we can chime @c42f, who can shed some light on how to improve both packages?

[FedeClaudi]

Yep, agreed, it's piracy, but as you say there's no clean way to replace the error system currently. Ideally there would be some hook like in python.

If this is something you would also find useful I'd be happy to open a discussion and maybe even PR for this in Base?

[c42f]

Great! Personally I think this would be useful and a more general showerror mechanism is needed in Base. Ultimately we should have something so (a) you don't need any piracy in this package and (b) authors of exception types can define various pretty printing - not just for text but for environments like Pluto.

I'm not 100% sure display() and the global display stack needs to be involved...

@fonsp who in Pluto-land would be interested in a better showerror? Would be good to make it work well for both use cases.

[fonsp]

We are SuPER interested in a better showerror! I find that Julia's error system is one of the big hurdles for beginner programmers, also compared to other languages with simpler errors (take a look at Elm!). I don't have any API suggestions right now, but we are very supportive of any development here and we would love to contribute 💖

[FedeClaudi]

that's awesome. It sounds like we have a consensus about its importance and a few important use cases (Term, Pluto JuliaSyntax) that are used extensively by the community and would benefit by something like this. I'm thinking perhaps the folks behind the VSCode Julia extensions might also be interested.

Should we move this to Julia's repository and maybe start a discussion there?

[fonsp]

That sounds good, although I think discussions on the Julia repo benefit from being more closed-ended – it would help if we come up with specific examples or suggestions before.

[FedeClaudi]

That's fair @fonsp

From my perspective, the main thing we'd need is a way to intercept errors and print them as one wants without requiring piracy.
Things are quite involved in Term.jl, but there's two main components to it:

• render_backtrace takes care of rendering the backtrace with extra stuff like hiding frames that shouldn't shown (e.g. in Base), showing the error line's source code etc..
• thent term does is to print a Panel with the error message.

I think in general if there was a hook for a print_stacktrace and a print_error_message function that would be enough. These would fallback to the current default functionality but there should be a mechanism to let users specify their own functions. Unsure what this should be though.

[FedeClaudi]

This is what a stacktrace currently looks like in Term. The first panel is the render_backtrace output while the second is the error message

[c42f]

I think for REPL pretty printing (which I assume is the main thing Term.jl is doing) we need to generalize Base.display_error() and make it relate in a sensible way to the multimedia system and Base.display(). Then make the REPL use this. Currently REPL printing is done here: https://github.com/JuliaLang/julia/blob/master/stdlib/REPL/src/REPL.jl#L294-L309

• The LineEditREPL uses specialdisplay as a way to display() normal output from evaluation, thus allowing a custom AbstractDisplay to direct the REPL output somewhere customized rather than hitting the global Base.displays stack.
• However the REPL uses a normal errio::IO passed to Base.display_error(), bypassing the whole multimedia system. This seems wrong.

If Term.jl set the REPL specialdisplay, I assume that would allow output to be captured and processed by Term as desired?

What to do about display_error and showerror?

One idea might be to generalize Base.display_error take an AbstractDisplay as the first argument and generalize showerror to be more like show in terms of mime types? Then plumb everything together in a similar way to how display() and show() relate to each other.

I'm not sure this can be done compatibly (especially regarding the kinda ad hoc way backtraces are managed in the API) and we might need to do this via different function names, but it's an idea to try.

Another maybe cleaner idea could be to add an ErrorVal wrapper type as a way to pass an error printing flag through the normal display system (having that defer to unwrapping the exception and printing in MIME"text/plain" via showerror?)

If we have sane interaction with the multimedia system I think this could sort out the needs of Pluto too.

[FedeClaudi]

I never really looked into how the REPL works, so I might be missing something. But wouldn't

If Term.jl set the REPL specialdisplay, I assume that would allow output to be captured and processed by Term as desired?

just work in the REPL? As in if I just run a script that wouldn't work right?

[c42f]

As in if I just run a script that wouldn't work right?

Right. But in that separate case of a script you could have an entry point wrapper - have the user call Term.run(user_func) to explicitly capture exceptions and process them inside Term without invoking piracy. This shouldn't be a big issue because the user already needs source like using Term in their script to get Term-based output?