How to get a clean stacktrace in v0.6

General Usage
1

The stacktrace in 0.6 is nicely formatted in the REPL - but when I display it in the browser, it’s unreadable. Can I get a clean representation of the stacktrace?

Stacktrace:
 [1] e[1mmatch_routese[22me[22me[1m(e[22me[22m::HttpCommon.Request, ::HttpCommon.Response, ::Sessions.Session, ::Router.Params{Any}e[1m)e[22me[22m at e[1m/Users/adrian/.julia/v0.6/Genie/src/Router.jl:462e[22me[22m
 [2] e[1mroute_requeste[22me[22me[1m(e[22me[22m::HttpCommon.Request, ::HttpCommon.Response, ::IPv4e[1m)e[22me[22m at e[1m/Users/adrian/.julia/v0.6/Genie/src/Router.jl:86e[22me[22m
 [3] e[1mhandle_requeste[22me[22me[1m(e[22me[22m::HttpCommon.Request, ::HttpCommon.Response, ::IPv4e[1m)e[22me[22m at e[1m/Users/adrian/.julia/v0.6/Genie/src/AppServer.jl:122e[22me[22m
 [4] e[1m(::AppServer.##1#9)e[22me[22me[1m(e[22me[22m::HttpCommon.Request, ::HttpCommon.Responsee[1m)e[22me[22m at e[1m/Users/adrian/.julia/v0.6/Genie/src/AppServer.jl:25e[22me[22m
 [5] e[1m(::HttpServer.#on_message_complete#14{HttpServer.Server,HttpServer.Client{TCPSocket},Bool})e[22me[22me[1m(e[22me[22m::HttpCommon.Requeste[1m)e[22me[22m at e[1m/Users/adrian/.julia/v0.6/HttpServer/src/HttpServer.jl:427e[22me[22m
 [6] e[1mon_message_completee[22me[22me[1m(e[22me[22m::Ptr{HttpParser.Parser}e[1m)e[22me[22m at e[1m/Users/adrian/.julia/v0.6/HttpServer/src/RequestParser.jl:113e[22me[22m
 [7] e[1mhttp_parser_executee[22me[22me[1m(e[22me[22m::HttpParser.Parser, ::HttpParser.ParserSettings, ::Array{UInt8,1}e[1m)e[22me[22m at e[1m/Users/adrian/.julia/v0.6/HttpParser/src/HttpParser.jl:115e[22me[22m
 [8] e[1mprocess_cliente[22me[22me[1m(e[22me[22m::HttpServer.Server, ::HttpServer.Client{TCPSocket}, ::Boole[1m)e[22me[22m at e[1m/Users/adrian/.julia/v0.6/HttpServer/src/HttpServer.jl:389e[22me[22m
 [9] e[1m(::HttpServer.##7#8{HttpServer.Server,Bool})e[22me[22me[1m(e[22me[22me[1m)e[22me[22m at e[1m./task.jl:335e[22me[22m
2

Either use a regexp to get rid of the ANSI control codes yourself or start julia with --color=no (I think).

3

Or alternatively, perhaps there is some javascript library that can format the strings as nice html?

4

In my opinion the error stack should be formatting independent. The error stack is about data, and data should be separated from presentation.

In this case I display it on the web (so I’d want text or HTML). In other cases I log it to a text file (so text). In others, I might want to send it as a JSON response (so JSON). And so on…

5

If you catch the stacktrace you can display it however you want. What you showed is just the way the REPL decides to present it.

6

Well, the data doesn’t have the formatting built in, only the default printing to STDERR, IIRC. If you want the StackTrace object for further manipulation, you’ll have to catch the error yourself and not rely on the default printing.
Also, @kristoffer.carlsson is right, you can parse the ANSI codes (atom-ink does this too, if you wanna have a look).

7

Thanks for your input @pfitzseb and @kristoffer.carlsson

I’m using

sprint(io->Base.show_backtrace(io, catch_backtrace())

to display the error in the browser, in a user friendly way.

show_stacktrace is not documented, I found it digging through other sources, looks like that’s the culprit…

I’ve been struggling a lot with getting useful and readable stacktraces and the above was the best option in v0.5. I guess it’s back to the drawing board now in 0.6, I’ll have to just render the raw stacktrace myself.

Thanks!

1 Like
8

Have a look at https://github.com/JunoLab/Atom.jl/blob/master/src/display/errors.jl for inspiration (you could actually almost take that code verbatim, since it kinda spits out HTML).

1 Like
9

Thanks @pfitzseb, that looks great!