[tormeh]

Partial disagree. There should be lints against 'unwrap's. An 'expect' at least forces you to write down why you are so certain it can't fail. An unwrap is not just hubris, it's also laziness, and has no place in sensitive code.

And yes, there is a lint you can use against slicing ('indexing_slicing') and it's absolutely wild that it's not on by default in clippy.

[milliams]

  [lints.clippy]
  dbg_macro = "deny"
  unwrap_used = "deny"
  expect_used = "deny"

[tormeh]

Exactly. This should be the default for production code at companies like Cloudflare.

[echelon]

https://github.com/search?q=unwrap%28%29+language%3ARust&typ...

This is sobering.

My new fear is some dependency unwrap()ing or expect()ing something where they didn't prove the correctness.

Unwrap() and expect() are an anti-pattern and have no place in idiomatic Rust code. The language should move to deprecate them.

[an_ko]

I use unwrap a lot, and my most frequent target is unwrapping the result of Mutex::lock. Most applications have no reasonable way to recover from lock poisoning, so if I were forced to write a match for each such use site to handle the error case, the handler would have no choice but to just call panic anyway. Which is equivalent to unwrap, but much more verbose.

Perhaps it needs a scarier name, like "assume_ok".

[echelon]

I use locks a lot too, and I always return a Result from lock access. Sometimes an anyhow::Result, but still something to pass up to the caller.

This lets me do logging at minimum. Sometimes I can gracefully degrade. I try to be elegant in failure as possible, but not to the point where I wouldn't be able to detect errors or would enter a bad state.

That said, I am totally fine with your use case in your application. You're probably making sane choices for your problem. It should be on each organization to decide what the appropriate level of granularity is for each solution.

My worry is that this runtime panic behavior has unwittingly seeped into library code that is beyond our ability and scope to observe. Or that an organization sets a policy, but that the tools don't allow for rigid enforcement.

[kevin_thibedeau]

> the handler would have no choice but to just call panic anyway

The handler could log the error and then panic. Much better than chasing bad hunches about a DDoS.

[ok123456]

Unwrap is in a lot of example code.

If you're using Result<T,E>, there's no automatic language feature for statically typing a nested E that mirrors how it was called.

So out of brevity, they unwrap.

Expect to see this sort of error crop up a lot as people use LLMs to vibe with the borrow checker.

[ViewTrick1002]

What would the difference be if they had enforced no unwraps/expects/slicing and instead logged the error and returned a 500?

As the user, I can't tell the difference, but it might have sped up their recovery a bit.

[tomtomtom777]

You could argue that explicitly writing down the assumption would make it clearer to yourself and your reviewer that it might be overly optimistic.

[ljm]

Pretty much - the time spent ruling out the hypothesis that it was a cyberattack would have been time spent investigating the uptick in deliberately written error logs, since you would expect alerts to be triggered if those exceed a threshold.

I imagine it would also require less time debugging a panic. That kind of breadcrumb trail in your logs is a gift to the future engineer and also customers who see a shorter period of downtime.

[selfmodruntime]

I would love to go further and explicitely forbid unwrap and similar calls using a `no_panic` attribute.

[stevefan1999]

I actually have to do this for programs that runs in bare metal. You can't afford to have nondeterministic panic like this. If things really gone wrong you'd have a watchdog and health checker to verify the state of program.

[selfmodruntime]

How do you manage to do this?

[stevefan1999]

There's a crate that prevents linking panic symbol in the final stage of the executable generation, forcing it to be undefined symbol, so while it is hard to find out where the panic is, it effectively requires me to inspect throughout the code to find out. Sometimes I have to disassemble the object file to see this

[selfmodruntime]

it's not the `no_panic` crate by david tolnay, is it?