Live data from Hacker News

Pretty Rust backtraces in raw terminal mode

werat.dev

1–10 of 16 posts

Re: Pretty Rust backtraces in raw terminal mode

#4
I’m not a rust expert, but perhaps this usecase is particularly hard because you’re holding it wrong? It seems to me that the strength of rust is in preventing panics as much as possible by moving the error checking to the compiler; so sure, fixing the terminal is an interesting challenge, but probably not going to make development any easier.

Re: Pretty Rust backtraces in raw terminal mode

#5

I’m not a rust expert, but perhaps this usecase is particularly hard because you’re holding it wrong? It seems to me that the strength of rust is in preventing panics as much as possible by moving the error checking to the compiler; so sure, fixing the terminal is an interesting challenge, but probably not going to make development any easier.

You can easily make lots of fragile Rust code by poor error handling that cause shitty panics like "Some(2) != None" and suppressing backtraces for even more obscurity. Good backtraces need to be human- and machine-readable. Ideally, you'd throw (pun intended) panic objects (not backtraces) as structured data in individual files. Anyone who gets into reinventing flat log rotation management at scale is holding it wrong.

Re: Pretty Rust backtraces in raw terminal mode

#6

I’m not a rust expert, but perhaps this usecase is particularly hard because you’re holding it wrong? It seems to me that the strength of rust is in preventing panics as much as possible by moving the error checking to the compiler; so sure, fixing the terminal is an interesting challenge, but probably not going to make development any easier.

I think the key there is "as much as possible". It's really hard to guarantee that panics won't happen.

I like Rust, but the panic mechanism is a bit of a weak point in the language. It's not like I have a better solution -- you really do need a way to handle exceptional cases that shouldn't ever happen but aren't statically checkable. But it's unfortunate that it interacts with so many other parts of the language, rather than being orthogonal. Every single API needs to answer "but how does this interact with panics". Rust is a very good language because panics are one of just a couple of things that work this way.

Re: Pretty Rust backtraces in raw terminal mode

#9
post #3

Hmm just adding some ASCII art doesn't really make it pretty. Colorizing the output and making it easier to analyze as well as read, would.

The article wasn't about adding ASCII art, only about allowing the default panic handler to print the output correctly when the application uses raw mode in the terminal. It is a good introduction to what registering a panic handler looks like, no more than that. If you want colored backtraces, you can look at https://crates.io/crates/color-backtrace, https://crates.io/crates/better-panic or https://crates.io/crates/color-eyre, which leverage the same machinery shown in the article.

Re: Pretty Rust backtraces in raw terminal mode

#10
post #3

Hmm just adding some ASCII art doesn't really make it pretty. Colorizing the output and making it easier to analyze as well as read, would.

In this article, I interpret "pretty" to mean "readable". There is a sample of the alternative in the post. Raw mode requires an explicit carriage return to accompany each line feed if you want the CR behavior, so if the default panic handler prints its normal string, each line is horizontally indented to the end of the previous line.

There is no ASCII art.

Post reply on HN