It's a nice idea. See also this related idea.
So, there are two main types of errors we usually deal with: programmer errors, and expected exceptions.
This operator does not seem like a good fit for programmer errors - these are fatal errors that should only be caught for logging/reporting purposes, so let's focus on exceptions that a user of the API may want to catch and handle in different ways.
Any time an exception is thrown, there's usually something provided to be able to distinguish one exception from another one. Some libraries will create different subclasses of Error, and you have to do an instanceof check to know which type of exception you caught. Others will set some unique property on the error object itself (for example, node sets the "code" property to "ENOENT" when throwing a file-not-found exception).
When dealing with exceptions, it's good practice to be as specific as possible in your error handling. e.g. when reading a file, if you expect that the file might not exist, catch and handle just that specific exception, and let all others continue to propagate. You wouldn't want to accidentally handle a "disk full" exception in the same way.
The current proposal has no way to cherry-pick which type of exception you're handling, instead, you're swallowing up all kinds of errors - programmer errors or non-programmer exceptions, FileNotFound or DiskFull, and treating them all the same. I fear the way this is currently proposed would encourage some bad programming practices.