While this is a Java example to do with testing and wiremock, it relates to a more universal problem.
We were trying to retry Wiremock’s
verify method, which may be called by our test before the endpoint we’re checking is hit. In that situation, we’d want to try again a few seconds later in a loop until timing out. Interesting, the Wiremock client doesn’t provide a method like this, but meh, they’re easily created.
The type of object thrown was called
VerificationException so we wrote something like this:
It didn’t work. Our catch block wasn’t hit.
Digging deeper, and always read the source code of the open source libraries you use, it seems like the
VerificationException is derived from
Error is not an
Exception. So why is the
VerificationException not called the
catch block needed to catch
Throwable to work. Which it now does and it does work.
What Went Wong?
This is a case of violating the principle of least surprise. Because the thrown object was called exception, nobody would imagine that it was anything else. We needed to write a failing exception catcher, debug it, and read a couple of classes deep in the source code to find this mistake. Was it our mistake for expecting an exception to be an exception?
You can easily explain why they chose the misleading name, but if you have to explain something that violates the norm, then you would be better putting the effort in to make it not require an explanation.
Opinions expressed by Java Code Geeks contributors are their own.