[vermilingua]

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]

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]

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.

[pornel]

Unsafe code needs to be paranoid about panics, because that’s equivalent of exception safety in C++.

However, other safe Rust code doesn’t need to care that much, because it will either unwind and run destructors, or abort the program. Both are well defined and safe.

Rust uses panics to signal programmer bugs, not normal error handling, so there isn’t much to do about them in the code, because actual “handling” of panics is fixing the bug.

[ddulaney]

Sort of. There are a bunch of places in the safe API where you have to care. Off the top of my head:

- Lock poisoning and dealing with locks failing to open because they’re poisoned after some other thread panics.

- The whole scoped thread thing.

- Panics across async calls have a bunch of unintuitive (but reasonable once you think through the constraints!) behaviors.

It all comes down to the same thing: a function call could return or it could panic. Even when writing safe code, you have to know what you’re doing to do in case of panic. Usually that’s just passing the panic upward*, but not always, and those behaviors aren’t well-captured in the type system. Because of that, writing truly panic-free Rust is hard to impossible.

I don’t have a better answer than the panicking system. But you do have to care even in safe code, and it is a design weakness.

* I know about panic handlers and abort-on-panic. It doesn’t change the overall point.

[zokier]

I'd say having panics is one of the strengths of Rust; panics cause controlled teardown of the program (typically) instead of nasal demons