Not really. In C or C++ that could have just been a segfault.

.unwrap() literally means “I’m not going to handle the error branch of this result, please crash”.

Indeed, but fortunately there are more languages in the world than Rust and C++. A language that performed decently well and used exceptions systematically (Java, Kotlin, C#) would probably have recovered from a bad data file load.

▲

koakuma-chan an hour ago | parent [-]

There is nothing that prevents you from recovering from a bad data file load in Rust. The programmer who wrote that code chose to crash.

▲

mike_hearn an hour ago | parent [-]

That's exactly my point. There should be no such thing as choosing to crash if you want reliable software. Choosing to crash is idiomatic in Rust but not in managed languages in which exceptions are the standard way to handle errors.

	▲	koakuma-chan an hour ago \| parent [-]
		I am not a C# guy, but I wrote a lot of Java back in the day, and I can authoritatively tell you that it has so-called "checked exceptions" that the compiler forces you to handle. However, it also has "runtime exceptions" that you are not forced to handle, and they can happen any where and any time. Conceptually, it is the same as error versus panic in Rust. One such runtime exception is the notorious `java.lang.NullPointerException` a/k/a the billion-dollar mistake. So even software in "managed" languages can and does crash, and it is way more likely to do so than software written in Rust, because "managed" languages do not have all the safety features Rust has.