You've got that backwards. When you need to get real shit done you use languages that have a proper type system that eliminates all possibility of exceptions. Given a sufficiently advanced compiler, the absence of exceptions can be proven at compile time.
Letting your program enter into an undefined state where it could wreak all kinds of havoc without anyone realizing beforehand is only acceptable in low-rung "webshit" development.
You can imagine an end user has some structured document created by some other program 10 years ago and they need to look at it. Unfortunately in one place it violated the spec and a field type is wrong. Two ways to deal with it.
My way. The program catches the error, notifies the user, tries to mitigate it and display the contents it can extract to the user.
You might want to read the thread again. You seem confused.
> The program catches the error, notifies the user, tries to mitigate it and display the contents it can extract to the user.
As you will see once you do, that's also my way. Only if you encounter an exception would you exit. As you point out, and to which I agree, your scenario is not exceptional. It is correctly identified as an error. You literally state as such, just as I would.
Again, exiting is reserved for exceptions. Encountering an error is not exceptional. Encountering an error is expected!
Letting your program enter into an undefined state where it could wreak all kinds of havoc without anyone realizing beforehand is only acceptable in low-rung "webshit" development.