You are assuming the use of exceptions is an evolution in the first place, but that's far from being a consensus. To some of us, exceptions are very convenient, but more easily lead to brittle software.
I wrote a little bit about that before. Probably won't help you much, except perhaps in acknowledging that there's a different angle to that which some people may care about.
Exceptions are, when you boil it down to the core, a default behavior for error conditions. It states that, on error, execution jumps to the first point in the code path expecting the error. If no such point exists, execution halts.
This is a stark contrast to the default behavior for error returning, which is to carry on as if nothing happened. How can "keep calm, carry on" be construed as better is beyond me.
Now, I know the arguments against exceptions are supported on all kinds of horror code using exceptions out there. Let me preempt that by stating that assessing a tool for its wrong uses is not a good evaluation of the tool. A hammer is not a good screwdriver, there are no news there.
It's not about horror stories, but about choosing a tool that makes it easier to get the error handling path right, which is just as real and important as the success case. In my experience with the medium sized projects I've been closely responsible for (in the hundreds of thousands of lines ballpark), we were interested in doing a really good job in both the exception and the error result cases, because the misbehavior scenario is a real issue, and followed all the good practices in the modern developer's backpack. In the end, exception-rich code just turned out obviously hard to get right, no matter how much we _wanted_ to get it right, because the program is allowed to jump out of arbitrary stack frames that the developer was conveniently taught to not handle errors on, because.. hey! the "default behavior"!
After getting involved in these experiments, I started paying more attention to how people can possibly be happy with exception-rich logic that behaves like that. My empiric observation is that the lack of proper error handling turns out to have a relatively low impact for lots of projects. Crashed or misbehaved? Whatever.. file a bug.
Just read your post. It's the poor coder theme, a variant of the poor code theme. Sorry, I don't code poorly and I'm not about to shackle myself for fear of a nonexistent boogeyman.
Ah, I see, you're still in the upwards trend of thinking you have a superior mind. Been there.. eventually I learned that I too suck, and need all those tricks that encourage me and the teams I work with to up the stakes in terms of project quality.
I wrote a little bit about that before. Probably won't help you much, except perhaps in acknowledging that there's a different angle to that which some people may care about.
http://blog.labix.org/2013/04/23/exceptional-crashes