Avoid crashing on error sometimes: more control over the failure mechanism

[Pascalio]

Related problem

New to nu (sorry^^) but as far as I can gather, currently, as soon as there's an error, the whole nu script will terminate with the error message. While the message is quite detailed and useful, this might not be enough or simply not be desirable. My current case:
open corrupt_file.json
echo "In case of corrupt file, call the Doctor.
The last informative message can never be printed because the script will have crashed before.
Alternatively, you may also want to take some default actions if the json file seems corrupt, without terminating the script, say open backup.json...

Describe the solution you'd like

Without allowing the risk of leaving corrupt data in our pipelines, there may be options, like in Rust, to continue the operations or to terminate more gracefully. (Please forgive me if there are already, really haven't found them yet.)
Suggestions:

Error handler parameter

Certain commands could take some --error_handler <Block> that gets executed after the error message is printed.
The error_handler could have a default implementation for all types, which results in the current behaviour. So if no user-defined implementation shadows it, things would stay the same.
But if the user needs to, the error_handler can be re-implemented; it could have automatic access to error structure as well.

Return a type Result instead of terminating

The hardcore Rustacean's pick... Could look like this:
open data.json | ok_or $error_handler | get something if the error is to be dealt with; or
open data.json | unwrap | get someting if we don't mind crashing.

It is worth noting that, currently, nu terminates indifferently on 2 very different kinds of problems:

1. an error in the script
2. an error from the outside
   While a coding error should probably cause immediate termination, data from the outside can't be relied on: it should be dealt with differently than the usual internal errors. So maybe we'd just need an IOResult, whereas the rest could stay as it is.

Describe alternatives you've considered

To avoid crashing on error, open --raw corrupt_file.json works, but then you're basically left on your own with structured data to parse and you can't use the builtins as they would crash on error too.

Additional context and details

No response

[Pascalio]

So, what do you think about this somewhat burning issue? Or is there any suitable workaround?