Oh, and I think there’s a big difference between flow control and being able to safely ignore / recover from an exception. The next step of execution shouldn’t be relying on whether or not we got an exception. It should be able to safely continue, but it should not fork the logic. Perhaps a better example of this would be to catch the SqlException and decide to try it in Oracle. (In that example, go back to square one and use an Interface.) If you utilize an Exception to determine whether or not you’ve been passed a null reference, maybe you need to rework that one a little bit.

I’m not saying exceptions are fundamentally flawed. I’m saying reserve them for when things are absolutely out of your control, or for where you know 100% (not 99) that you can safely move past an exception without a problem. Those are what I think you can consider “exceptional.”

I am fully in agreement when you say things like: “Rewrite that code without exceptions and it doesn’t get any better. It may get faster, but the speed issue isn’t exceptions’ fault either- that is still just faulty code.” “Well, no one can say either- which is why null should be an invalid argument to Frob and Frob should throw an exception.” However, I agree because I think try / catch usually gets added to the mix in the wrong occasions only to mask this.

The real questions here are why are we trying to divide by 0 and why are passing a null Sprocket? This is something that could indicate a large problem at the root level. Try/Catch/Ignoring the problem is probably not the right call. Now, that kind of depends based on the architecture of the system. Obviously a web server or an MMO server should not blow up. However, that still doesn’t mean it’s okay to sweep the error under the rug. That information needs to be surfaced. I guess the code sample was a little too vague to convey the message. You’ll notice that if SomeRiskyOperation doesn’t complete, we totally return true as if we did everything we needed, because maybe when someone was working on this code they got an exception that COULD be ignored. Now the Exception is that we can’t connect to the database and nothing is working. It’s still an SQLException, and maybe the third party you’re using only provides one type of named Exception. (You’ll notice I didn’t even use System.Exception in the example. If you ever sweep that one under the rug…)

If you know you’re going to pass an Invalid Argument to a function half the time, why bother calling that function in the first place? Granted, code that throws an Exception should leave an object untouched instead of in a heinous state, but why do all that work?