This question got me thinking about the ratio between the number of exception throw sites and the number of try blocks in my own code. A swift grep on a couple of non-library projects indicated it is something like 150 throws to 1 try. This kind of surprised me - I was expecting something like 50 to 1 - and I wondered if others would like to share approximate figures here.
And a supplementary question - if you were setting down some coding guidelines, what would an "ideal" ratio be?
I don't have any numbers to give, but if I were to set up a coding guideline, I would say it should be generally quite a bit less than that, say 15-to-1. My argument is that an exception should be exceptional and specific. How can you possibly handle 50 different error conditions in 1 place? I understand that some of them are actually the same error, but that still seems high.
In my current hobby project (an implementation of a C and C++ preprocessor), there are currently 293 throw expressions and two try blocks.
Effectively, it's written such that an exception is thrown whenever an unrecoverable error occurs, and there isn't much in the way of error recovery (at least at the moment).
I've been playing around a bit with using a form of Scope Guard with a diagnostic handler to accumulate detailed error information as the stack is unrolled, but haven't yet decided whether it is useful enough or practical to use in production code.
I think that the ratio is wholly meaningless. I might structure, say, a compiler, by throwing compilation errors as exceptions, and using one try to log the exception and abort compilation. In that instance, I might have one try to catch every single possible compilation error, which may be an exceedingly large number (e.g., a C++ compiler/linker/preprocessor) or very few (my Brainfuck interpreter).
The quantity of situations that can be handled identically is entirely application dependent.
Fundamentally, the fact that one try may catch an infinite number of throws suggests to me that you would need contextual data to even suggest that any given ratio is good, bad, or anything else, hence, application dependent.
In addition, grep will not demonstrate this to you. There's many throws that exist, even though realistically if such a thing occurs, you won't be able to recover. For example, you could suggest that operator new might throw a std::bad_alloc on Windows if you hit the virtual address limit, and count that as a throw. However, in reality, I would never catch such an exception- I don't know of any meaningful way to recover from such an exception. You would have to check out every throw and it's corresponding catch.
In a project i co-own we have roughly 1307 throws vs. 88 trys due to somewhat uncommon requirements: