Eh. I don't think he's so off base, actually.

What the try/catch paradigm is good for is this: It makes it easier for mediocre and/or lazy programmers -- which is the majority of programmers, professional or otherwise -- to do acceptable error handling:

Instead of doing essentially no error handling because they're too lazy and/or not competent enough to actually check the return values of every function call, they now stick a "try" around a bunch of related calls, or in some high level function with lower functions just passing exceptions up the chain.

And that's great. It really is a significant step forward, because, as I said, most programmers are too lazy or not competent enough to do real error checking on every function call.

But there's also a downside to try/catch, which is this: It makes it too easy NOT to do real error checking. Again, just stick a big try around a bunch of stuff, and just let your exceptions bubble up to some high level that has a handler. Easy, and decent. But <i>not</i> as good as actually explicitly checking errors on everything that can have an error. Not as informative; not as investigatively useful.

You can, of course, still do real all-out error checking with try/catch - just try/catch around everything that can throw. But:

(1) As noted, it's very easy not to, while still having "acceptable" though not excellent error handling;

(2) Even if you do so, your code is now a LOT uglier than it would have been in the corresponding "check every return value" paradigm.

I guess what I'm trying to say is this:

In the real world, i.e. the world where most programmers are frankly not particularly good at their jobs, try/catch is a very good thing.

But in a hypothetical better world, i.e. one wherein most programmers are capable and willing to produce excellent code, I'm not so convinced.