Leveraging Java Type System to Represent Special States
Tags: java, beginners
Published: 2021-09-03 09:04:31

---
title: Leveraging Java Type System to Represent Special States 
published: true
description: Make special states explicit
tags: #java #beginners
//cover_image: https://direct_url_to_image.jpg
---
As every Java developer know, variables with non-primitive types are initialized to `null`. This is the Java (and not just Java) way to say that "value is missing" or "variable has no value assigned yet". 

There are often situations when we may return value, but sometimes we need to notify the caller that there is an error. The idiomatic Java way to do this is to throw an exception.

What described above situations have in common? They cover different cases and use different ways to represent/handle them.

In fact, both of them deal with _special states_ of the variables. There is also a third special case, as you'll see below.

## Variable Special States

What is the variable special state? The special state of the variable is the state, when the value of the variable is not (yet) available for some reason. 

There are three special states of the variables:
- Variable value is missing
- Operation may return a value or report an error, so a value might be present or not
- Variable holds a result of the asynchronous operation which is still in progress, so the value is not yet available.

Let's take a look how these cases handled traditionally.

### Missing Value

The traditional Java way to represent missing is to assign a `null` to the variable. This approach has several drawbacks and is a source of a huge number of errors. 
Funny enough, even Java itself does not threat such variables as real ones, with real type - `instanceof` check for such variables returns `false`.

### Return Value or Report Error

The traditional way in Java to report failure is to throw an exception. Since Java uses dedicated syntax to throw and catch exceptions, often this case is hard to even see as a special state of some variable. Needless to say, that exception handling syntax is verbose, hard to compose and quickly gets unreadable in non-trivial error handling cases. 

But this is only part of the issue. As you already know, there are two types of exceptions - checked and unchecked. 

Checked exceptions pollute the code with boilerplate, although, at least, provide information which exceptions can be thrown. Language also enforces handling or propagating them, so, in theory, they should result in more reliable code. Unfortunately, verbosity makes them so inconvenient, that developers tend not to use them or wrap into unchecked exceptions.

Unchecked exceptions keep code less verbose, but the price for this is the complete lack of support from the compiler side. Such exceptions too easy to overlook. Many seasoned developers have a habit of looking into the body of the invoked method to make sure that it does not throw an unchecked exception. This extra navigation and code reading slows down the process and causes mental overhead.

### Not Yet Available Value

Since version 8 Java has built in support for handling this case - `CompletableFuture`. Built on FP-inspired concepts, it uses the following approach to handle not yet available value: instead of letting user code access the value, `CompletableFuture` has a number of methods, which accept functions (lambdas) as a parameter. The invocation of these functions are postponed until value is available.

Notice, that this approach is quite flexible and does not require any special support at the language level.

## Finding Consistent Approach

Even though an idiomatic approach to each case is different, intuitively looks like they should have similarities. 

Functional Programming provides a convenient tool to bring all these cases under the common umbrella - [monads](https://dev.to/siy/beautiful-world-of-mondas-2cd6).

Each special state corresponds to a particular monad:
- __Option/Optional/Maybe__ monad handles the missing value case
- __Result__ monad handles the value/error case
- __Promise__ monad handles the case of not yet available value

Monads leverage the Java type system to represent special states, and this provides numerous immediately sensible advantages:
- All special states are immediately visible in the code. There is no need to spend time navigating and reading code to make sure that it does/don't return `null` or throw an exception.
- Significantly reduced boilerplate code and improved code readability. All repetitive checks like `if (variable != null)` disappear and developer can write code as if there is only "happy day scenario", leaving final decision to the caller.
- Compiler is your best friend, which makes sure that every single special case is covered and properly handled.

In the long run, there are more subtle, but no less valuable advantages:
- Together with the Java 11 `var` declaration and type inference, monad-based code has almost all redundant type declarations shaved off.
- There is a natural tendency to break code into small, generalized, reusable, easy to read and understand, focused on single task functions.
- Reduced boilerplate makes business logic much more visible in code, easier to read and understand. Overall code base looks and feels more high level. 
- Significantly reduced number of bugs, especially low-level ones like missing `null` check or unhandled exception.
- Code is simpler to test, usually less mocking is necessary.
- Handling of special states happens transparently and for typical backend code the whole call chain can be easily navigated back and forth. There is no hidden execution paths like dedicated exception handlers which have no visible link to the code, but may affect the resulting response.
- Significantly reduced mental overhead, which enables deeper focus on high level business logic and significantly improves productivity.