# Cyclomatic complexity when calling same method multiple times

Thanks to a question over at Code Review I got into a little disagreement (which essentially is an opportunity to learn something) about what exactly the Cyclomatic Complexity is for the below code.

public static void main(String[] args) {
try {
thro();
thro();
thro();
thro();
thro();
thro();
thro();
}
catch (NullPointerException e) {
}
}

private static Random random = new Random();

public static void thro() throws NullPointerException {
if (random.nextBoolean())
throw new NullPointerException();
System.out.println("No crash this time");
}


When writing this code in Eclipse and using the Eclipse metrics plugin, it tells me that the McCabe Cyclomatic Complexity for the main method is 2, and for the thro method it says 2.

However, someone else tells me that the complexity of calling thro multiple times is number of calls * method complexity, and therefore claims that the complexity of the main method is 7 * 2 = 14.

Are we measuring different things? Can both of us be correct? Or what is the actual cyclomatic complexity here?

• The CC of the function is two, as there are only two paths through. The CC of the program is higher. This is a complete stab in the dark, but I assume code analysis software takes each function as a separate black box due to the infeasibility of calculating the CC of an entire complex application in one go. Commented Nov 29, 2013 at 14:57
• @Phoshi If you would write that as an answer and (if possible) provide links that shows that there is a separation of the two, I'd gladly accept that answer. Commented Nov 30, 2013 at 16:56
• If you count all paths caused by possible exceptions in CC measurements, god help the guy who asked the question on refactoring some trivial code to get the number under 10. Commented Dec 5, 2013 at 20:42

When I understood this correctly, the Cyclomatic Complexity of main is 8 - that is the number of linearly independent paths through the code. You either get an exception at one of the seven lines, or none, but never more than one. Each of that possible "exception points" corresponds exactly to one different path through the code.

I guess when McCabe invented that metric, he did not have programming languages with exception handling in mind.

• But does it really matter which of the lines that throws the exception? Commented Nov 29, 2013 at 15:21
• @SimonAndréForsberg: yes, it does. Think of "thro" having a side effect where it increments a global counter when it is called (that would not change the possible paths through the code). The possible outcomes of that counter then are 0 to 7, so this proves that the CC is at least 8. Commented Nov 29, 2013 at 15:24
• Would you say that the metrics plugin I am using is reporting an incorrect value for the main method? Commented Nov 29, 2013 at 18:26
• @SimonAndréForsberg: well, I don't know your metrics plugin, but 2 is obviously not 8. Commented Nov 29, 2013 at 18:35
• ..continued: I believe the argument about side-effects does not hold here - for example, having a while cycle that does GlobalCount++ and has a completely unrelated exit condition, there are still just two execution paths, regardless of the value (internal state) of GlobalCount at the time of exiting the cycle. And that is different from short-circuiting of boolean operators which do increase CC as they generate implicit decision nodes. Commented Jul 2, 2019 at 14:12

Being 'the other guy', I'll answer here, and be precise about what I say (which I was not particularly precise with over on other formums).

Using the code example above, I calculate the cyclomatic complexity as 8, and I have comments in the code to show how I calculate that. To describe the paths I will consider a successful loop through all the thro() calls as the 'main' 'code path' (or 'CP=1'):

public static void main(String[] args) {
try {
// This is the 'main' Code Path: CP = 1
thro();  // this has a branch, can succeed CP=1 or throw CP=2
thro();  // this has a branch, can succeed CP=1 or throw CP=3
thro();  // this has a branch, can succeed CP=1 or throw CP=4
thro();  // this has a branch, can succeed CP=1 or throw CP=5
thro();  // this has a branch, can succeed CP=1 or throw CP=6
thro();  // this has a branch, can succeed CP=1 or throw CP=7
thro();  // this has a branch, can succeed CP=1 or throw CP=8
}
catch (NullPointerException e) {
}
}


So, I count 8 code paths in this main method, which, to me is a Cyclomatic Complexity of 8.

In Java terms, each mechanism for exiting a function counts to it's complexity, so, a method that has a success-state, and, throws, for example, possibly up to 3 exceptions, has 4 documented exit paths.

The complexity of a method which calls such a function, is:

CC(method) = 1 + sum (methodCallComplexity - 1)


I think other things to consider, is that, in my opinion, the catch clause does not contribute to the complexity of the method, the catch is simply the target of a throws branch, and thus a catch block that is the target of multiple throws counts 1 time for each throw, and not just once for everything.

• Are you counting the possible branches for OutOfMemoryExceptions too? I mean pedantically they can cause code branches, but nobody counts them as they dilute the usefulness of the metric. Commented Nov 29, 2013 at 15:37
• No, I'm not... and you're right, but, in the context of this argument, I count only the exceptions the method is declared to throw. Also, if a method declares three exceptions, but the callinch code does a catch (Throwable t) {... then I gues it does not matter how many exceptions it declares to throw. Commented Nov 29, 2013 at 15:40