[HN Gopher] Pretty Rust backtraces in raw terminal mode
       ___________________________________________________________________
        
       Pretty Rust backtraces in raw terminal mode
        
       Author : werat
       Score  : 40 points
       Date   : 2023-02-24 20:16 UTC (2 hours ago)
        
 (HTM) web link (werat.dev)
 (TXT) w3m dump (werat.dev)
        
       | wkat4242 wrote:
       | 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.
        
         | estebank wrote:
         | 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.
        
         | kaelinl wrote:
         | 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.
        
       | zaynetro wrote:
       | Does anyone know of a good solution to pretty print or make more
       | sense of stacktraces in async code?
        
       | Vecr wrote:
       | Raw terminal mode is used for TUI programs, so the article is
       | about setting a panic hook to get everything working in that
       | case.
        
       | vermilingua wrote:
       | 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.
        
         | 1letterunixname wrote:
         | 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.
        
         | ddulaney wrote:
         | 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.
        
       | david2ndaccount wrote:
       | I'm glad the author finally figured out that the abstraction he
       | was using was the wrong one and just ended up using a C-like API
       | - calling some global procedures that mutate the (external)
       | global state.
        
       ___________________________________________________________________
       (page generated 2023-02-24 23:00 UTC)