Rust has no exceptions in any sense of the word. Exceptions are ways to crash the program in a controlled manner with the ability for these crashes to be caught midway before the program crashes and handled correctly.
In rust you can only crash it explicitly using the panic! Macro. No handling.
The different name you are looking for is "errors". Rust has errors as do all programs. Some programs have exceptions to handle those errors. Rust does not.
If you mean "runtime crashes" then elm is the only language that is popular that uses has no runtime crashes.
[0] Example of catching, handling, and "swallowing" a panic in Rust (GTP4 wrote this): https://play.rust-lang.org/?version=stable&mode=debug&editio...
Trying to do magic and patch something on a panic and retry is cursed indeed. If it's about cleaning up resources of a thread and logging this somewhere, then there's nothing cursed about this.
> In rust you can only crash it explicitly using the panic! Macro. No handling.
You can catch Rust panics with `catch_unwind()` if you compiled your program with `-Cpanic=unwind` (default on most platforms). Under the hood it uses stack unwinding, just like C++ and co, exceptions. But Rust doesn't consider this idiomatic error handling, it's only used in a few special situations (biggest ones are test frameworks, and web servers where one buggy session shouldn't take down the process).
fun findUser(userId: String) : Either<Error, User>
is MUCH simpler and more powerful than
fun findUser(userId: String) //haha, I can actually throw exceptions that aren't in this signature, or return null (wat)
I hope you never program any safety critical machinery. I don't mean exceptions cannot be useful, just that there are circumstances where they are useful and circumstances where they are not.
IMO the biggest problems with almost all popular programming languages are
1) null
2) exception based error handling
such that, when you call foo() where foo is
String foo(){ blabla }
you can get a String, null OR an exception (!!!) and most compilers happily let you treat it as if it only ever returns a String.
I hope some day null is no longer a thing, and that Functional Programming types like Option, Either, Try etc in the native libraries is the new default.
incredibly, there's still no consensus as to which exceptions should be used for what and when, though these days the most common approach is to simply stick only to RuntimeExceptions, which is terrible.
Functional error handling using Option, Either, Try etc are arguably much simpler, safer and more powerful than exceptions.
Simpler because they don't rely on dedicated syntax- they're just regular objects no different to any other object.
Safer because unlike exceptions, they force callers to handle all potential outcomes, but no more. (no risk of ignoring errors and no risk of catching a higher level of error than desired, ubiquitous bugs in exception based error handling)
Powerful because they support map, flatmap, applicative etc, making it easy to eg chain multiple computations together in desired ways, which is unwieldy and bug prone when using exceptions.
It could be that, when learning Java, Python and any other language, we learn that methods return objects... and that's that. No weird dedicated syntax and magic, special treatment for returning anything other than the happy path, and the HUGE complexity that comes with it, eg the dedicated syntax itself and how it behaves, differences between checked and unchecked exceptions, hierarchies of exceptions etc etc.
In addition to that, when lists and booleans implement map, flatMap etc, you can actually reduce syntax of languages even further- there's no need for looping syntax like for, while etc, and no need for if else either. This is probably too extreme for most people, but think about it.