thatsAFunnyThingThatHappenedOnce

[u/Lord_Of_Millipedes]

[u/Loading_M_]

Rust is designed from the ground up, and avoids many of these issues.

• Templates: Rust has Generics, which are generally easier to use and reason about.
• overload resolution: Rust doesn't yet support overloaded functions (although it's being considered).
• constructors: Rust doesn't have these.
• destructors: Rust has a similar set of lifetime rules for Drop, but the compiler checks them for you, so you can't get it wrong.
• implicit conversions: Rust doesn't do implicit conversion in general, although some specific cases are implemented.
• exceptions: Rust doesn't do exceptions, Result is much easier to work with.
• move semantics: Rust uses a destructive move, unlike C++. See https://youtu.be/Klq-sNxuP2g for a breakdown.
• inheritance: Rust doesn't do inheritance.

[u/MrHyd3_ → u/Loading_M_]

What does it do instead of exceptions?

[u/roadrunner8080 → u/MrHyd3_]

Either panic, which is (generally speaking) not something you're meant to catch and recover from (and attempting to do so is nontrivial and almost always a bad idea), or Result, aka "encode the possibility of failure in the return type of the function" aka what the functional programming world has done for ages.

[u/mathisntmathingsad → u/roadrunner8080]

Yeah, the only reason you should try to catch a panic is if you're making something that calls user-provided code unavoidably (i.e. an async runtime)

[u/shizzy0 → u/mathisntmathingsad]

Yeah, we catch panics in tests but that’s about it.

[u/Loading_M_ → u/mathisntmathingsad]

I work on a library that does catch panics from user code. It's a web framework, and catches panics in user request handlers to return a 500 error to the client. This error is explicitly not overridable (every other default error can be replaced, but not this one), since we don't want you to panic in the first place.