|Problems? Is your data what you think it is?|
Why are you ignoring all other of my points?
I addressed the only point I saw as relevant. Your "points" are not arguments; they are a fait accompli.
In not so many words, your position amounts to: If it ain't object-oriented, it ain't right.
You are of course welcome to hold that opinion, but there are other programming paradigms.
And people were reliably handling errors and exceptions for many years before OO took hold of the collective imagination. And the techniques used then are still just as reliable as they ever were. Google for "ABEND" to see a system that been working just fine for a very long time.
But exceptions are not a magic bullet that will fix badly architected code.
For me, it is the very crux of the issue. OO doesn't automatically fix all sins; and code does not have to be OO to be good or reliable.
I'd argue that inspecting user error messages for error type determination is bad code.
Worded that way, you're right.
But omit two pernicious little words and you get: inspecting error messages for error determination".
Which is exactly what has been going on in Perl, and many other languages, for decades. And perfectly successfully thank you.
And your determination to see it as "bad code" just highlights your own blinkered outlook.
And I'd argue that attempting to fix architectural problem by layering OO over everything, is the second most pervasive ill of the software industry today. It's not just "bad code", but bad education.
Suggesting that :
is both: to deny history; and hopelessly naive.
It's attempting to dictate a programming monoculture. And monoculture is bad in any field.
Examine what is said, not who speaks -- Silence betokens consent -- Love the truth but pardon error.
"Science is about questioning the status quo. Questioning authority".
In the absence of evidence, opinion is indistinguishable from prejudice.