Mastodawn

@CyReVolt Forbidding unwrap is reasonable, but forbidding expect seems nonsensical. Why would you want that?

@anselmschueler Both are intentional panic!()s in the end, one with no message, the other one with a message. Either way, it takes away the possibility from e.g. a library consumer to handle errors properly, and is usually not expected. An app would just crash.
Especially graphical apps or infra services do not intend to crash, but rather give feedback on / report errors when they occur.

@CyReVolt

The point of panics is that they should occur on programmer error, not on exceptional circumstances. A program that is correctly written will never panic, and the point of a panic is to alert the user that the program has a mistake in it.

A panic is assumed to be unrecoverable without a surrounding runtime. You can make that runtime and catch the panic for something like service respawning and logging the panic somewhere.

For something like a user application, crashing is the correct response to a panic.

@CyReVolt I can see that people might use these in other ways though, in which case a warning in case of unwrap usage might be OK? I’m not sure

@anselmschueler Yea that's the whole point; it's not clear when linting what the semantic idea behind or reason for a panic would be.
Just bear in mind that typical users of (graphical) apps are usually far away from the code and would not understand the reason should a crash occur. It just appears to be a quality issue to them.
Graceful error handling is not trivial, but a sign of software quality.
And yes I know that runtimes can pick up a panic etc. - they shouldn't have to for libraries.

@anselmschueler I.e., the combined lint would be useful for any library author who would currently have to add a typical set of lint rules.
It would make sense to look at some hundred library repos and check them for typical combos of lints used for library crates, on that note. 🤔

@CyReVolt I feel like a GUI app having a panic hook that shows an alert like “A critical error has occurred!” with a button to copy the traceback and a link to the issue tracker or support page is reasonable

@CyReVolt I think honestly the OS should provide that. That way you aren’t reimplementing this a million times, and more bugs in that dialog can be caught.

@CyReVolt It would also automatically add this to old apps.

@anselmschueler
There are coredumps etc already.
The problem is that the OS cannot know about any specific language's internals without getting quite bloated. It would work with an additional user-space runtime.

The question to a GUI is not *how* it presents an error, but *whether* it can handle it meaningfully. Of course, programmers are not perfect. I'm calling for self-discipline here where the mechanisms to avoid bubbling up panics already exist.

Reasoning here:
https://platform-system-interface.github.io/intel_fw/extend.html

Extend with new variants and features - intel_fw

@anselmschueler So in the end, I want to avoid generic error handling where possible, following the idea also documented in the Clippy lint rules:
https://mastodon.social/@CyReVolt/115604191992034336

laund Nov 24

@CyReVolt Without reading the issue, my guess is that its quite complex depending on the interpretation: Is the intention to remind yourself to not use unwrap/expect in your own code? In that case, do you need a lint? It would be nice to have ofc, but a grep for unwrap\( and expect\( would cover that too.

But if the intention is to forbid panics, no matter how deep they happen, well, now you have a whole different beast on your hands. At the point clippy can access, every array[i] is a potential panic, for example, even if its surrounded in a explicit check that returns a Result/Option. Because you kinda need optimisations to understand "oh its already checked, we can skip the bounds check for the index access". That's why https://docs.rs/no-panic/latest/no_panic/ is optimization-level dependent, and code compiled in release might pass it while in debug it might find a panic.

Anyways, gonna look at the issue now and see how right i was.

no_panic - Rust

github crates-io docs-rs

laund Nov 24

@CyReVolt Okay so, i wasn't entirely right: The primitive versions already exist, as the lints unwrap_used and expect_used. The issue authors usecase is covered already, so i think the issue is left open for the suboptimal messages for unwrap_used telling people to use expect, and maybe because people keep asking to enable them by default.