Groovy gotcha: Passing zero arguments to a method that expects one

I was recently adding a parameter to a legacy method, and after updating all the callers of the method, I found that I was still getting a MethodMissingException. That was strange, since the old method took one required parameter, and the exception was being thrown on a line which called a method of the same name with no arguments. My first reaction was that it couldn’t possibly be the same method I was updating, but… I was wrong. Apparently Groovy will compile just fine in certain scenarios where no arguments are passed to a method that expects one.

For example, only the second call below throws a MissingMethodException:

The first one will compile and run without issue, and will print “null” to the console. That’s unexpected, but it makes sense given that we accept an object (this works with any object, as far as I can tell). The second call fails because it expects a primitive, and I guess Groovy does not resolve to pass any “default” values to it. You can try this out in the Groovy web console, if you want to play around with it yourself.

Upon compilation, you may think that Groovy implicitly creates a zero-arg method similar to having an optional parameter, but examining the class’s methods proves otherwise; whereas the required parameter version only yields public void SomeClass.doSomething(java.lang.Object), the optional one really does compile to two methods: public void SomeClass.doSomething(java.lang.Object) and public void SomeClass.doSomething().

The fact that there is no zero-arg method means that this is a special case, rather than a rule of passing n-1 arguments to a method. This is clearly demonstrated if we try to add another parameter to our method, and call it with only one argument. This is true even if the new parameter is optional with a default value:

The first call above will throw a MethodSelectionException, while the second will throw a MissingMethodException but we are mostly back in the realm of “expected” Java behavior.

This may be common knowledge to some, but other developers I spoke to were not aware of this behavior. It’s certainly interesting, but I wouldn’t advocate it as best practice. It seems clearer and more maintainable to simply make a parameter optional, rather than relying on Groovy to pass the null value. However, if you’re refactoring a method signature and find yourself getting some unexpected behavior, hopefully this post can shed some light.

Igor Shults

About the Author

Object Partners profile.

One thought on “Groovy gotcha: Passing zero arguments to a method that expects one

  1. Joe says:

    Makes sense…kinda. If null is nothing, then foo(null) would be equivalent to foo(); in both cases, we’re calling the method and passing in “nothing.” But this doesn’t work other way around: I cannot define an argument-less method and invoke it with a single null argument. So I suppose the takeaway is: nothing is null but null isn’t nothing.

    1. Igor Shults says:

      Yeah what got me though is that it only works for single-argument methods, even when the method takes a second optional parameter. It just seems a little inconsistent and I couldn’t find it documented anywhere.

      This is almost JavaScript-y behavior, but only in a limited case.

Leave a Reply

Your email address will not be published. Required fields are marked *

Related Blog Posts
AWS Cloud HSM, Docker and NGINX
There is quite a bit of easily searchable content on the security benefits of leveraging a Hardware Security Module to manage cryptographic keys, so I will leave that to the scope of another article. The […]
Google Professional Machine Learning Engineer Exam 2021
Exam Description A Professional Machine Learning Engineer designs, builds, and productionizes ML models to solve business challenges using Google Cloud technologies and knowledge of proven ML models and techniques. The ML Engineer is proficient in all aspects […]
Designing Kubernetes Controllers
There has been some excellent online discussion lately around Kubernetes controllers, highlighted by an excellent Speakerdeck presentation assembled by Tim Hockin. What I’d like to do in this post is explore some of the implications […]
React Server Components
The React Team recently announced new work they are doing on React Server Components, a new way of rendering React components. The goal is to create smaller bundle sizes, speed up render time, and prevent […]