Birthing code is not always easy.

Enough puns. Let’s talk about Java exceptions. No matter how hard you try, your code will likely encounter an error and throw an exception (if your language supports exceptions.) It could be anything from unexpected user input to an underlying service outage. An exception will be thrown and it’s important to do something useful with it. That doesn’t mean putting try-catch blocks everywhere or trying to recover everything, in-fact I’ll argue the opposite in a few situations.

This post introduces a few common issues I’ve seen when working with Java code-bases and developers that lead to poor debuggability or other operational pains.

In late 2023, Intuit announced that Mint was going to be shutting down and migrating everybody to Credit Karma. I could try out Credit Karma, but maybe it’s time to explore alternatives. Since that announcement came out, I launched a massive time sink to try and find a new option I liked.

In a previous post, I noticed that all my Kubernetes services with type=LoadBalancer were exposing some internal services as NodePorts which meant that I might be exposing internal services to the Internet at high ports. I was running Kubernetes directly on my dedicated servers and not behind a load balancer. Kubernetes expected everybody to sit behind a LB which often times required a NodePort.

The solution was to set the Service spec.allocateLoadBalancerNodePorts value to false when the service is created. This works if I can set it while I create the Service, however Helm based templates often wouldn’t allow me to set this and once it was set to true and the node port was allocated it was difficult to deallocate the NodePort.

In this post, I walk through using a Kubernetes mutating webhook to automatically set the value for all Services.