Though in some cases like that I think it might be appropriate to use `catch_unwind()`.
So, on a micro-level, let's say I have a function that expects x to be a float between 0 and 1, and there's some math and logic built on this assumption. Of course, in development if this expectation is violated, we fail fast and loudly and then fix the problem. In production it's not quite so clear. But still, is it ever the right thing to ignore that an invariant is violated and just hope that things somehow work out?
> Make defects obvious during development so they don't exist when you deploy to customers.
I agree with this phrasing. From another viewpoint, I would say:
If your code checks an invariant, and that invariant is broken never (never!, not even in production) just continue on and hope that things will work out.
Yes! Of course! In many situations it probably doesn't matter that the numbers go a little wrong, and that result will be better than crashing. In other situations it will be better to crash than to give junk results. As we already said, it depends on the situation.
Stick to Result<T,E>.
> Users would rather see an error saying “whoopsie, maybe try that again later” than for the program to exit
To achieve this, you need to catch panics. Rust does not use Result for things the OP is talking about like asserts.
The reason panics/exceptions exist is it is too onerous to handle every possible error condition at all callsites (allocation failure and broken pipes are the famous examples), and it is not possible to enumerate all possible error conditions (unintentional programmer errors for example).
People have religious ideas about handling panics for some reason.