Maybe a Default Good Idea
Tags: maybe, functional, nullpointer, exception
Published: 2019-07-14 19:47:54

---
title: Maybe a Default Good Idea
published: true
description: While using Maybe's can remove null pointer exceptions from your code, providing default values in the case of Nothing can be dangerous. Learn how and what to do about it.
tags: maybe,functionalprogramming,nullpointer,exception
---

## Introduction

You’ve learned that using `Maybe‘s` allows you to get rid of null pointer exceptions (i.e. “undefined is not a function”). However, now your application fails and gives no indication as to why. At least errors would leave a stack trace that may provide a hint as to where the problem originated. How does this happen and what should you be doing instead?

## Null Pointers in Python vs Ruby, Lua, and JavaScript

Let’s define what we mean by null pointers first, and how you usually encounter them. Most null pointers you’ll run into as a developer are from either accessing a property of an `Object` to show on the screen or calling a method on an `Object` or class instance.

### Python’s Strict

Accessing Objects (Dictionaries in Python) is very strict. If the dictionary exists but the name doesn’t or you spell it wrong, you’ll get an exception:

```python
# Python
cow = { "firstName" : "Jesse" }
print(cow["fistName"])
KeyError: 'firstNam'
```

### Ruby, Lua, and JavaScript are Not Strict

Ruby, Lua, and JavaScript, however, will return a `nil` or `undefined` if you access a property that doesn’t exist on the Hash/Table/Object:

```javascript
// JavaScript
cow = { firstName: "Jesse" }
console.log(cow["fistName"]) // undefined
```

### Benefits of Getting Null/Nil vs. Exceptions

All 3 languages will return their version of “nothing”. For some applications, this works out quite well:

1. UI applications when displaying data
2. API’s that are for orchestrating many API’s or solely exist to get around CORS
3. any code dealing with NoSQL type of data

For UI’s, you typically do not control your data; you’re often loading it form some API. Even if you write this yourself, the names can get out of sync with the UI if you change things.

For API’s, you’ll often write [orchestration API’s for UI’s](https://samnewman.io/patterns/architectural/bff/) to access 1 or many API’s to provide a simpler API for your UI. Using yours, you’ll make 1 request with efficient, formatted data how your UI needs it vs. 3 where you have to do all the error handling and data formatting on the client. Other times you want to use an API, but it has no support for CORS. The only way your website can access it is if you build your own API to call since API’s are not prevented from accessing data out of their domains like UI applications are.

For NoSQL type data, you’ll often have many Objects with the same or similar type fields, but either it’s low quality, inconsistent, or both. Often this is user entered and thus there is no guarantee that a record has “firstName” as a property.

### Careful For What You Wish For

However, this has downstream effects. Sometimes code will be expecting a `String` or a `Number` and instead get `undefined` and blow up. Worse, the exceptions it throws are indicating the wrong place; the error occurred upstream but the stacktrace might not show that.

While the benefits to being flexible are good, using a `Maybe` to force a developer to handle the case where `undefined` is returned instead is better.

## Maybe’s To the Rescue

The way to solve this to use the Algebraic Data Type, `Maybe`. This gives you 2 ways to deal with null data. You can either get a default value:

```javascript
// Lodash/fp's getOr
getOr('unknown name', 'fistName', cow) // unknown name
```

Or you can match, whether using a [match syntax](https://folktale.origamitower.com/api/v2.3.0/en/folktale.maybe.html) provided by a library, or a switch statement using [TypeScript](https://www.typescriptlang.org/) in strict-mode which ensures you’ve handled all possible values:

```javascript
// Folktale's Maybe
cowsFirstNameMaybe.matchWith({
  Just: ({ value }) => console.log("First name is:", value),
  Nothing: () => console.log("unknown name")
})
```

This, in theory, is one of the keys to ensuring you don’t get null pointer exceptions because you ensure in any case you normally would, you now get a type, and force your code to handle what happens if it gets a null value, even if that so happens to be throwing a custom error.

## Downstream Still Suffers

However, Maybe‘s can still causing suffering downstream just like `undefined` can. They do this via default values. In the `getOr` example above, we just provided “unknown name”. If we get nothing back, we just default to “unknown name” and handle the problem later, or don’t if it’s a database data quality issue we can’t fix. For a UI developer, that’s often perfect as they can usually blame the back-end developers for the problem, and their code is working perfectly, and thus fire-drill averted, blame diverted. 💪🏻

![](https://thepracticaldev.s3.amazonaws.com/i/ibhindcptaxasyq8iej4.png)

Hey, at least it didn’t explode, right? I mean, the user finished the test, their results were submitted, and they can ignore the weird score…
However, other times, it ends up hiding bugs. For non-FP codebases, a downstream function/class method will get null data and break.

![](https://thepracticaldev.s3.amazonaws.com/i/lv5tn9bcanzc29d7hy11.png)

For Functional Programming codebases, they’ll get default data which often the developer never intended, and something goes awry. This is what we’ll focus on below.

## Examples of Default Value Causing UI Drama

Let’s define what we mean by default value as there is the imperative version where function arguments have default values for arguments if the user doesn’t supply a value, or a `Maybe` which will often come with a default value through `getOr` in [Lodash](https://lodash.com/docs/4.17.14), `getOrElse` in [Folktale](https://folktale.origamitower.com/api/v2.3.0/en/folktale.maybe.html), or `withDefault` in [Elm](https://package.elm-lang.org/packages/elm/core/latest/Maybe#withDefault).

### Default Values For Function Parameters

Default values are used by developers when methods have a common value they use internally. They’ll expose the parameter in the function, but give it a default value if the user doesn’t supply anything.

The date library moment does this. If you supply a date, it’ll format it:

```javascript
moment('2019-02-14').format('MMM Do YY')
// Feb 14th 19
```

However, if you supply no date, they’ll default to “now”, aka `new Date()`:

```javascript
moment().format('MMM Do YY')
// Jul 14th 19
```

Think of the function definition something like this. If they don’t supply a `maybeDate` parameter, JavaScript will just default that parameter to right now.

```javascript
function moment(maybeDate=new Date()) {
```

### Default Values for Maybes

While useful, things can get dangerous when you don’t know what the default values are, or if there are more than one, or what their relationship to each other is. In Moment’s case, it’s very clear what no input means: now. Other times, however, it’s not clear at all. Let’s revisit our default value above:

```javascript
getOr('unknown name', 'fistName', cow) // unknown name
```

What could possibly be the reason we put default value “unknown name”? Is it a passive aggressive way for the developer to let Product know the back-end data is bad? Is it a [brown M&M](https://www.snopes.com/fact-check/brown-out/) for the developer to figure out later? The nice thing about a string is you have a lot of freedom to be very verbose in why that string is there.

```javascript
getOr('Bad Data - our data is user input without validation plus some of it is quite old being pulled from another database nightly so we cannot guarantee we will ever have first name', 'fistName', cow)
```

Oh… ok. Much more clear why. However, that clarity suddenly spurs ideas and problem solving. If you don’t get a name, the Designer can come up with a way to display that vs “unknown name” which could actually be the wrong thing to show a user. We do know, for a fact, the downstream database never received a first name inputted by the user. It’s not our fault there is no first name, it’s the user’s. Perhaps a read-only UI element that lets the user know this? It doesn’t matter if that’s correct, the point here is you are investing your team’s resources to solve these default values. You all are proactively attacking what would usually be a reaction to a null pointer.

### Downstream Functions Not Properly Handling the Default Value

Strings for UI elements won’t often cause things to break per say, but other data types where additional code later expects to work with them will.

```javascript
const phone = getOr('no default phone number', 'address.phoneNumber[0]', person)
const formatted = formatPhoneNumber(phone)
// TypeError
```

The code above fails because `formatPhoneNumber` is not equipped to handle strings that aren’t phone numbers. Types in [TypeScript](https://www.typescriptlang.org/) or [Elm](https://elm-lang.org/) or perhaps [property tests using JSVerify](https://github.com/jsverify/jsverify) could have found this earlier.

### Default Values for Maybes Causing Bugs

Let’s take a larger example where even super strong types and property tests won’t save us. We have an application for viewing many accounts. Notice the pagination buttons at the bottom.

![](https://thepracticaldev.s3.amazonaws.com/i/nm9014m6fsnxgizhjn07.png)

We have 100 accounts, and can view 10 at a time. We’ve written 2 functions to handle the pagination, both have bugs. We can trigger the bug by going to page 11.

![](https://thepracticaldev.s3.amazonaws.com/i/qm2miraawm0aqfe2lktp.png)

I thought you just said we have 10 pages, not 11? Why is the screen blank? How does it say 11 of 10? I thought strong types and functional programming meant no bugs?

The first bug, allowing you to page beyond the total pages, is an easy fix. Below is the Elm code and equivalent JavaScript code:

```elm
-- Elm
nextPage currentPage totalPages =
  if currentPage < totalPages then
    currentPage + 1
  else
    currentPage
```

```javascript
// JavaScript
const nextPage = (currentPage, totalPages) => {
  if(currentPage < totalPages) {
    return currentPage + 1
  } else {
    return currentPage
  }
}
```

We have 100 accounts [chunked](https://lodash.com/docs/4.17.14#chunk) into an `Array` containing 9 child Arrays, or our “pages”. We’re using that currentPage as an `Array` index. Since Array’s in JavaScript are 0 based, we get into a situation where currentPage gets set to 10. Our `Array` only has 9 items. In JavaScript, that’s `undefined`:

```javascript
accountPages[9] // [account91, account92, ...]
accountPages[10] // undefined
```

If you’re using Maybe‘s, then it’s `Nothing`:

```javascript
accountPages[9] // Just [account91, account92, ...]
accountPages[10] // Nothing
```

Ok, that’s preventable, just ensure `currentPage` can never be higher than the `totalPages`? Instead of:

```elm
-- Elm
if currentPage < totalPages - 1 then
```

```javascript
// JavScript
if(currentPage < totalPages - 1) {
```

Great, that fixes the bug; you can’t click next beyond page 10, which is the last page.

![](https://thepracticaldev.s3.amazonaws.com/i/za1zae70ti7acthuykb9.png)

… but what about that 2nd bug? How did you get a blank page? Our UI code, if it gets an empty `Array`, won’t render anything. Cool, so empty `Array` == blank screen, but why did we get an empty `Array`? Here’s the offending, abbreviated Elm or JavaScript code:

```elm
-- Elm
getCurrentPage totalPages currentPage accounts =
  chunk totalPages accounts
  |> Array.get currentPage
  |> Maybe.withDefault []
```

```javascript
// JavaScript
const getCurrentPage = (totalPages, currentPage, accounts) => {
  const pages = chunk(totalPages, accounts)
  const currentPageMaybe = pages[currentPage]
  if(currentPageMaybe) {
      return currentPageMaybe
  }
  return []
}
```

Both provide an empty `Array` as a default value if you get `undefined`. It could be either bad data the index `currentPage` but in our case, we were out of bounds; accessing index 10 in an `Array` that only has 9 items.

This is where lazy thought, as to how a `Nothing` could happen results in downstream pain. This is also where types, even in JavaScript which doesn’t have them but can be enhanced with libraries, really can help prevent these situations. I encourage you to watch [Making Impossible States Impossible by Richard Feldman](https://www.youtube.com/watch?v=IcgmSRJHu_8) to get an idea of how to do this and prevent these situations from occurring.

## Conclusions

Really think about 4 things when you’re using `Maybes` and you’re returning a `Nothing`.

If it truly is something you cannot possibly control, it truly is someone upstream to handle it, that is the perfect use case, and why `Object` property access, and `Array` index access are the 2 places you see it used most.

Second, have you thought enough about how the `Nothing` can occur? The below is obvious:

```javascript
const list = []
console.log(list[2]) // undefined
```

But what about this one?

```javascript
const listFromServerWith100Items = await getData()
console.log(list[34]) // undefined
```

If accessing data is truly integral to how your application works, then you are probably better served being more thorough in your data parsing, and surfacing errors when the data comes in incorrectly. Having a parse error clearly indicate where data is missing is much more preferable than having an unexpected `Nothing` later but “hey, everything says it parsed ok….”

Third, be cognizant about your default values. If you’re not going to use a `Result`, which can provide a lot more information about why something failed, then you should probably use a better data type instead that comes embedded with information. Watch [“Solving the Boolean Identity Crisis” by Jeremy Fairbank](https://www.youtube.com/watch?v=6TDKHGtAxeg) to get a sense at how primitive data types don’t really help us understand what methods are doing and how creating custom types can help. Specifically, instead of `[]` for our `getCurrentPage` functions above, use types to describe how you could even have empty pages. Perhaps instead you should return a `Result Error` that describes accessing a page that doesn’t exist, or an `EmptyPage` type vs. an empty `Array` leaving us to wonder if our parsing is broke, we have a default value somewhere like above, or some other problem.

Fourth, these default values will have downstream effects. Even if you aren’t practicing Functional Programming, using default values means your function will assume something. This function will then be used in many other functions/class methods. She’ll provide some default value others further down the function call stack won’t expect. Your function is part of a whole machine, and it’s better to be explicit about what the default value is you’re returning. Whether that’s a verbose `String` explaining the problem, or a `Number` that won’t negatively affect math (such as 0 instead of the common -1), or a custom type like `DataDidntLoadFromServer`.

Making assumptions to help yourself or other developers is powerful, but be sure to take responsibility with that power and think through the downstream affects of those default values.