Years ago I was swearing at a particular application where I had to discover the undocumented behaviour buried under a truly clever engineering “technique”.
It was a typical monolithic Java EE application responsible for invoicing. The exact code is best to keep forgotten, but I recall that the developer had found a truly clever way to control the flow of a business process.
Part of the flow was a usual endless if-then-else mess, but what made things more “exciting” was that some random elements of those checks were buried into custom java.lang.RuntimeException handling mechanics.
I guess you might agree with me that this is one hell of a good way to make yourself indispensable. There is no freakin way someone is going to understand why the application is behaving like it is.
I recalled this experience due to the recent Plumbr optimization task at hand. I would like to say our code was not using exceptions the way the previous case was describing but this would unfortunately not be completely true. One particular method still had a RuntimeException constructed and thrown during a regular flow of the code. I only discovered this lone villain due to the performance anomaly in this particular module.
Usually an exception is thrown only when facing unexpected problems. So we don’t expect exceptions to be thrown by thousands per second per thread. But as I, you might discover a method which uses exceptions for more likely events.
I only found the culprit due to the fact that this was a frequently used code block in a particular graph traversing algorithm so it was crucial to squeeze the last milliseconds out of it. Removing the exception handling immediately made this code block to complete more than 100 times faster.
To see the explanation behind the lack of performance and the illustrating code samples, read the original blog post