What I've learned about distributed services (part three)

This is an anecdote really, but draws a very interesting conclusion.

As it turns out when you adventure yourself out of the boundaries of a single process/application (a.k.a. the monolith), you find yourself missing tools that used to make your life easier as a (monolith) developer. But it's the paradigm change that calls for a great deal of adaptation.

One of these things in Java land is the compiler's ability to "check" exceptions are handled properly, both downstream and upstream any method.

But once services become remote, the domain objects and their exceptions no longer live within the confines of a single repository, as is the case with a monolithic application.

Hence, the libraries you need are now IDL definitions and/or several RPC (or REST) APIs, which are not able to leverage the power of the Java compiler's checked exceptions feature.

So what I've found in some of the pre-existing code is that the authors started to use and abuse the runtime exceptions, as most services were only able to issue an RPC failure with an error code to the callers.

So, even when you were not dealing with remote calls, internal helper libraries only used runtime exceptions instead of the regular checked exceptions, effectively bypassing the compiler and freeing developers from doing any sort of exception handling.

I recall this was a double edge sword, as in some cases I found myself in the situation of needing exception handling. But overall (wink wink Golang) it wasn't too bad!

The way it worked was: every service had a top-tier exception handling code, so every runtime exception would bubble up and be caught by this code before returning to the caller. This provided for the proper error codes to be relayed to the caller, instead of just a generic runtime failure.

Now that I'm migrating a Spring application to Quarkus (and breaking it into microservices in the process), I'm learning that a few things are now different from the SOFA stack. I reckon the stack trace of the runtime exception can actually be sent back to the caller. I'll cover this a bit more of this in a future post.

For now, I think I understand now, why in a newer language like Golang, its creators took the bold decision to remove the checked exceptions feature. After all, if developers are working in a microservices environment, checked exceptions are less useful.