Some languages and style guides simply forbid throwing exceptions without catching / proper recovery. Google C++ bans exceptions and the main mechanism for propogating errors is `absl::Status` which the caller has to check. Not familiar with Rust but it seems unwrap is such a thing that would be banned.

▲

pdimitar 2 hours ago | parent | next [-]

There are even lints for this but people get impatient and just override them or fight for them to no longer be the default.

As usual: people problem, not a tech problem. In the last years a lot of strides have been made. But people will be people.

	▲	tonyhart7 2 hours ago \| parent [-]
		and people make mistake at some point machine would be better in coding because well machine code is machine instruction task same like chess, engine is better than human grandmaster because its solvable math field coding is no different

▲

kibwen 40 minutes ago | parent | prev | next [-]

> Not familiar with Rust but it seems unwrap is such a thing that would be banned.

Panics aren't exceptions, any "panic" in Rust can be thought of as an abort of the process (Rust binaries have the explicit option to implement panics as aborts). Companies like Dropbox do exactly this in their similar Rust-based systems, so it wouldn't surprise me if Cloudflare does the same.

"Banning exceptions" wouldn't have done anything here, what you're looking for is "banning partial functions" (in the Haskell sense).

▲

gpm 2 hours ago | parent | prev [-]

Unwrap is used in places where in C++ you would just have undefined behavior. It wouldn't make any more sense to blanket ban it than it would ban ever dereferencing a pointer just in case its null - even if you just checked that it wasn't null.

▲

an hour ago | parent | next [-]

[deleted]

▲

cherryteastain 2 hours ago | parent | prev [-]

Rust's Result is the same thing as C++'s std::expected. How is calling std::expected::value undefined behaviour?

	▲	gpm 2 hours ago \| parent \| next [-]
		Rust's foo: Option<&T> is rust's rough equivalent to C++'s const T* foo. The C++ foo is equivalent to the rust unsafe{ foo.unwrap_unchecked() }, or in safe code foo.unwrap() (which changes the undefined behavior to a panic). Rust's unwrap isn't the same as std::expected::value. The former panics - i.e. either* aborts the program or unwinds depending on context and is generally not meant to be handled. The latter just throws an exception that is generally expected to be handled. Panics and exceptions use similar machinery (at least they can depending on compiler options) but they are not equivalent - for example nested panics in destructors always abort the program. In code that isn't meant to crash `unwind` should be treated as a sign saying that "I'm promising that this will never happen", but just like in C++ where you promise that pointers you deference are valid and signed integers you add don't overflow making promises like that is a necessary part of productive programming.
	▲	9029 an hour ago \| parent \| prev [-]
		Tangential but funnily enough calling std::expected::error is ub if there is no error :D