Probably better to handle all out-of-bounds errors the same way.
i.e. a crash.
(Yes I know you can install signal handlers for segv, but that is not isolated at a language level like a task failure is with Rust.)
Granted, it is very rare that you can/should recover from nullpointer or OOB exceptions anyway. What you can do though is try to clean up things, show a polite message and shut down the application in a semi-controlled way.
"Preventing crashes" isn't the best description of Rust's novel protection systems. In my opinion, the best part is providing guarantees about data integrity and security, e.g. preventing heartbleed type read-overruns and preventing data races in concurrent code due to shared mutable state.
Actually it can be quite common, especially in complex web / network programs with many components. In Java such errors do not corrupt memory like in C, and since they are isolated, no reason not to continue the operation of the overall program. The error could just be due to a resource not being found, or faulty input coming from outside -- that is, nothing that prevents you from continuing to work on other requests.
That's somewhat like Erlang handles the case, if I am not mistaken.
But it seems you have your mind set, and wont accept any other answer.