Like @b3liever said you should always validate your user inputs because you should expect them to be wrong.
When you get an out-of-bounds or an exception, your program is in inconsistent state. Doing anything further has the heavy potential to do undefined things and potentially corrupt state even further. Crashing is a security measure to avoid propagating application corruption eventually down to a database or any storage. Not crashing is unsafe. Also crashing is not about errors, it's about exceptions, something that is unexpected. If you can expect that an input will be wrong (because it's from "outside"), don't use exceptions, validate with error codepaths. That was the main idea between TaintedString. Regarding numbers for example, one should always validate before dividing in case the input is 0, because that will bring down the application with a SIGFPE and this is emitted at the level below the application. This means if some exception kinds become more unforgiving (i.e. Overflow becomes DivByZero-like => no recovery), Nim should provide a way to validate those before committing to the operation (i.e. check overflow before)
