Good ratio of catch statements to lines of code

Question

Are there any rules of thumb as to how many catch statements you'd expect per source line of code in a large piece of software?

For instance, in one piece of software written in C#, Visual Studio shows up about 350 lines containing the word "catch", and cloc reports that we have about 160k SLOC, 30k commented lines, and 15k blank lines. 160k/350 is roughly 467 lines of code per catch statement.

But take that with a grain of salt, because we use standard C# formatting with braces on their own lines, so who knows how many lines are just single braces out of the 160k, and that 160k is counting some files in the tree that are no longer compiled in to the application, etc. I might guess the "useful" ratio to be closer to 1 catch per 400 LOC.

At least not to my surprise, we were missing a semi-critical exception that was getting caught in an empty catch block, so now I'm going through the code base and at least printing out the exception to the debug console as a temporary measure, or becoming more specific on the exception caught. This will of course increase the number of catches we have in the whole application, but will it bring us anywhere closer to the "acceptable" zone? I have no idea if 1 catch per 467 LOC is good, just okay, or horrible even.

---

I'm well aware of why not to use empty catch blocks. The other/previous maintainers have been lazy. And since the next release of this product is time-critical, I don't currently have the time to go in and properly fix all 300(?) poor catch statements and verify proper operation of the software (of course we have virtually no automated testing to make that easier :/ ).

I was just looking for if there was any kind of "gut feel" as to how frequently one should see try-catches. There's a couple answers saying it's context-sensitive, which is what I kind of suspected but was not sure of.

Answer 1

You should not be catching exceptions unless you're actually going to handle them. Unless the handler can "undo" the exception, or add value in some other way, you should allow the exception to bubble up to someone who can handle it.

Answer 2

It's very hard to give a general figure - it will really depend on what the application is meant to be doing and whether it needs to perform operations which may well fail in a recoverable way.

The big point to take away is that empty catch blocks are a really, really bad idea. That's much more important than lines of code per catch block.

Answer 3

I would completely ignore any metrics like this. Counting lines of code is not necessarily useful metrics - especially when looking for ratios.

The real answer here will completely depend on the context. The "right" number of catch statements is the amount of try/catch blocks required to handle the exceptions that may happen, which you will handle correctly. You should have a try/catch block around any exception that is likely to occur which you can properly handle. If you cannot handle it (or do not wish to handle it) properly, let it propagate upwards - do not catch it.

The amount of catch blocks will completely depend on what type of code you're writing. If you're writing networking code, for example, you'll be more likely to have more exception handling in place (since networks are, by nature, more likely to have issues that need to be handled).

Answer 4

As a very rough metric, my rule of thumb is to have at least one in every event handler that will log the exception.

With respect to the other methods, I prefer to have them try-catch-free; with that being said, there are many times that I've added catch blocks to add state to troublesome error reports ("parameter = value") then just "throw" out to the primary handler. If you're good with your bug fixes, this approach leads to a lot of dead code.