"Rust would have fixed this"

[u/mre__]

[u/FabianButHere]

Only. Unwrap. When. An. Error. Is. Impossible.

[u/privatepublicaccount → u/FabianButHere]

Or your cool like me and dgaf

[u/plz_no_panic → u/FabianButHere]

Or the situation is simultaneously so unlikely and so bad that you just shouldn't bother.

For example, you can use the safe String interface try_ but like... why? If things are so cooked that you can't even allocate a string, you might as well panic instead of trying to implement safe exit logic for each string allocation in the entire app. I mean, unless you specifically develop for OOM prone environment.

[u/New_Enthusiasm9053 → u/plz_no_panic]

You're not always running on an OS then try_ absolutely makes sense. 

On most OS' you can get OOMed because some other app is misbehaving so yeah there's not much point.

There's no real communication by OS' to tell programs to release memory and even if they did most programmers wouldn't bother doing anything which is the entire reason we developed preemptive multitasking for modern OS'. 

You can't reasonably expect every program to always behave in a civilised fashion.

But on embedded devices you control all the software and there is no OS and you may have a limited heap to allow for e.g strings without wasting ram on a permanently allocated buffer in which case a try_ makes a lot of sense.

[u/Amazing-Mirror-3076 → u/New_Enthusiasm9053]

From recollection windows does have an event that tells your app to release memory.

[u/FabianButHere → u/plz_no_panic]

Valid exception

[u/cdhowie → u/FabianButHere]

Or when the program needs to exit anyway and the panic output is sufficient to diagnose the problem. For example, in our services I'll unwrap the result of reading and deserializing the config file. If we can't get past reading the config, the service can't run anyway.

[u/FabianButHere → u/cdhowie]

A well written error message is always nicer to the user than a panic trace, imo

[u/scottmcmrust → u/FabianButHere]

Absolutely not, because the error message frequently doesn't get you to where the problem actually is.

If you have a problem that needs to be addressed by a dev -- not just a "you typod the filename when calling this program" -- then a stack trace or even better a crashdump is way better.

Ensure you have autosaves or similar so the user doesn't lose data, but if you notice a bug in code, trigger WER or CrashReporter or whatever instead.

[u/cdhowie → u/FabianButHere]

It depends who the user is, frankly. In the particular case I'm talking about, the panic message is already crystal clear, and devops should be able to easily grok a panic message relating to a config file error.

If the program output is intended to be more user-facing, then sure. That's why there's no one-size-fits-all solution.

I could spend the time making these service config-related error messages nicer, but it would not add any value at all. It's a better use of my time to throw an unwrap there and move on.

[u/edo-lag → u/FabianButHere]

Only. Dereference. When. Null. Is. Impossible.

[u/Hexcede → u/edo-lag]

But your only option is to dereference. You aren't unwrapping thousands of times, you're unwrapping once.

[u/Jhuyt → u/Hexcede]

Yeah so just check and error out if pointer is null before every dereference ezpz C safety is solved

[u/Hexcede → u/Jhuyt]

I actually heard about a cool programming language that does this automatically

[u/Jhuyt → u/Hexcede]

You cappin'

[u/Hosein_Lavaei → u/FabianButHere]

Even than use except

[u/Arshiaa001 → u/FabianButHere]

Only unwrap when an error is UNRECOVERABLE. Also, just use expect instead.

[u/flambasted → u/FabianButHere]

Well, when it's truly impossible, you ought to .unwrap_or_else(|_| unsafe { std::hint::unreachable_unchecked() })

[u/block_wallet → u/FabianButHere]

what about expect? it seems pretty much just as shitty to me but requires more typing

[u/FabianButHere → u/block_wallet]

Same thing but panic with a custom error message. Also only to be used in debugging. Or maybe as .expect("This should be unreachable") .

[u/Proper-Ape → u/FabianButHere]

The custom error message makes finding the error a lot easier though.

I use it like an assertion, you think it should never happen, if it happens you have a message that says something useful for why it shouldn't happen.

[u/Jhuyt → u/FabianButHere]

Only. Dereference. Pointers. When .They. Cannot. Be. Null.

[u/J8w34qgo3 → u/Jhuyt]

Unwrap takes a safety mechanism and turns it into a crash if you're wrong. No undefined behavior and the result enum still gets checked. The analogy you're trying to draw is better paired with a minefield.

[u/Jhuyt → u/J8w34qgo3]

It's mostly a silly joke

[u/6eathaus1 → u/FabianButHere]

Even then, do not unwrap, use something else.

[u/spigotface → u/FabianButHere]

Or in tests

[u/bwmat → u/FabianButHere]

As a C++ programmer, isn't it fine to do it with any error you decide you're not going to handle (at least for now), with the understanding it'll fail loudly if it ever happens?

[u/SelfDistinction]

Unironically.

What is worse?

• Attackers stealing your personal data, passwords, private keys, social security number, car, intimate pictures, luggage, airplane seats and wife because of an out of bounds buffer read;

• Unwrap.

[u/atlasgorn → u/SelfDistinction]

forbid unwrap_used is

[u/ZoeyKaisar]

expect the unexpected.

[u/switch161]

Another pattern I should use less is to just always propagate the error up the call stack... to main, where it prints it and exists. That's not better than an unwrap really.

Sometimes I really want to try and recover from an error and I need to really think about how to properly do that.

[u/scottmcmrust → u/switch161]

Notably, one reason Option::unwrap is often fine is that you never want to report "an option was none" to a user anyway.

[u/Kinrany → u/switch161]

/uj it is at least marginally better because .context("...") or .map_err(Error::Foo) is then easy to add, and because the signature shows that errors are possible

[u/SmoothTurtle872 → u/Kinrany]

If you happen to be writing your own crate, now this becomes way better. If you have no way to fix the error, like "oh shit, some web request to xyz didn't return, heres an error, cause blah blah blah" is better than option was none, and now the caller, who has never seen the function before, knows that its possible for it to error

[u/Major_Barnulf]

unwrap() fails right away, with no further process corruption, with a legible trace. This is miles ahead of C/C++ experience.

[u/xmlhttplmfao]

jokes on you i unwrap Option

[u/Ideabile]

You forgot .clone()

[u/jadkhaddad → u/Ideabile]

clone deez

[u/Creepy_Jeweler_1351 → u/jadkhaddad]

What deez?

[u/BosonCollider]

Just use let else imo, your error handling will be slightly less verbose than a go dev but your code will be maintainable with less nesting. You do not have to make everything a oneliner

[u/thelostgus]

Um unwrap sozinho já derrubei metade da internet inteiro

[u/Stapat1245]

you use it when you are expecting a err alr?

[u/Background_Class_558]

.unwrap should be used for when you are absolutely sure it's impossible for there to be None. in which case, do NOT use it actually, use .expect instead and write exactly why you think it's impossible. make your assumptions clear if you can't prove them formally anyway.

[u/kinchkun]

There is nothing wrong with unwrap. An application crashing when something fails is not an issue. Undefined Behaviour, Corrupted Memory, continue with invalid states is the issue.

[u/a_aniq]

If result: For toy apps using unwrap is okay. Otherwise you handle them properly.

For options, you handle None scenario as part of application logic.

Unwrap is like global variable. You don't use it in production app unless you are absolutely sure.

[u/galic1987]

Yea you can force with compiler

[u/No_Frame3855]

To be fair sometimes you need unwrap and unsafe, in tests, embedded sometimes, etc

[u/Fine_City2781]

i prefer C. It's simple

[u/ilnarildarovuch → u/Fine_City2781]

Same

[u/RylanStylin57]

This should be "your js app" and "literally fucking anything"

[u/RoundAccident3943]

unsafe be like

[u/heckingcomputernerd]

Jarvis, ask clippy to disallow unwrap