Nicollet.Net

From what I gather, many significant users of Objective Caml are moving away from exceptions, opting to rely on return types instead. To the more traditional C#/Java/C++ worlds, this must certainly sound as a heresy — exceptional situations should be handled using exceptions in order to avoid mudding up the control flow. Right?

Wrong.

Exceptions are a powerful tool that lets the author of a function say «heck, no way I can do this, let’s tell the caller» while letting the caller of that function say «I don’t care about your problems, tell my caller» and so the exception, once thrown, bubbles up through the hierarchy of function calls until it reaches a point where it can be handled. Which, in the vast majority of cases, is in some sort of catch-all handler that basically amounts to «drat, it didn’t work, let’s do something else»

As the writer of the calling function, this makes your life easier: if any errors happen in the functions you call, they will nicely bubble up, so you only have to care about situations where everything works fine. As a human being, you are passing the responsibility for handling that failure to someone else on your team who will happen to write the code that calls your code. And a major problem with responsibilities being passed around is that they end up on the floor.

This is further compounded by the fact that the presence of exception handlers is not adequately verified by compilers, and you end up with code in a mess that can only be solved in two ways:

• Read through all the code again, remember what functions might throw which exceptions, and add any missing handlers to treat them on the spot. This is hard.
• Add a generic catch-all handler that silences errors but doesn’t really react to exceptions in an acceptable manner.

Maybe your team does handle all exceptions appropriately in the places where they are needed. That would be quite surprising (where do you work?) but let’s assume for a moment that this is the case.

What happens when a change of specifications mandates that a new kind exception needs to be thrown? Suppose, for instance, that a given database resource may be now locked by an user, making all attempts to access that resource (by other users) fail. How do you change your code to handle this new requirement?

Adding a new exception is perhaps one of the single most painful kind of code change in modern programming, because it is woefully ill-supported by both languages (by design) and tools. It would effectively require the «functional specs guy» to think of all the ways an user might trigger that lock condition and how the software should react, then provide the developers with a detailed plan of action that would let them jump into dozens of different code locations to add the appropriate try-catch block. If one such location goes unnoticed, it will be filed as a bug when a tester or customer noticed («I tried to save my document, but it said document locked and I lost my data!»).

Consider the following example:

let get_age (person : Person.t) =
  if Person.is_dead then raise PersonIsDead ;
  Date.subtract Date.today (Person.birth_date person)

I just added the exception-throwing line — how can I easily detect locations that are affected by this change? There is no way. So, what is the alternative?

Eliminating Exceptions

Objective Caml allows the use of polymorphic variants. You can create a tag on the fly and attach it to a value that you’re returning (the tag is called a polymorphic variant constructor). You can also return tags without attached values, which is helpful when signaling error conditions. Here is how I would rewrite the above:

let get_age person =
  if Person.is_dead then `person_is_dead
  else `age (Date.subtract Date.today (Person.birth_date person))

I used the tag `age to represent a valid age, and `person_is_dead to represent the fact that a dead person has no age. Looking at the compiler output confirms that my function was indeed identified as returning a tagged value, and all possible tags were described by the compiler in the function signature:

val get_age : Person.t -> [ `person_is_dead | `age of int ]

Since the return type of the function changed (after all, it used to be int), all the functions that call it now cause a compiler error, which makes them quite easy to find and correct. Most of them will usually correspond to what the «functional specifications guy» wrote in his document, but the compiler will also find those that were overlooked. For instance, there’s this line that displays the age of a person:

 printf "%s %s (age %d)"
  (Person.firstname)
  (Person.lastname)
  (get_age person)

Seeing this code, but not seeing anything about it in the specification document, the programmer asks the stakeholder in the next scrum meeting, and the latter decides that showing deceased would be enough. So, the code becomes:

printf "%s %s (%s)"
  (Person.firstname person)
  (Person.lastname person)
  (match get_age person with `age a -> sprintf "age %d" a | `person_is_dead -> "deceased")

Pattern matching is a powerful tool from the ML family of languages. It behaves like a switch, but with several added benefits:

• It extracts any values attached to the tags, and the compiler checks the presence and types of those values. So, if I tried to access the a value from the `person_is_dead tag, the compiler would complain that no such value exists — the type signature of get_age specifies that no value is attached to `person_is_dead.
• It verifies that all possible tags are handled by the construct. So, if I had to hide the age of all female users, I would return `is_woman and the compiler would point out that said tag is not handled in the above code — an interesting tool when adding more exceptional cases.

Preventing Exceptions

But that is not all. Having the compiler as an ally also helps the programmer prevent exceptions in the first place. For instance, suppose that, on the online profile page of every user, I have a tab that shows a countdown to the next birthday of that user. The code looks like this:

let show_user_profile person url = (* ... *)

let show_birthday_countdown person url =
  printf "%d minutes left to age %d"
    (get_minutes_to_birthday person)
    (get_age person)

let profile_page person url =
  (* This renders both tabs, then checks which one is 
   * active based on url and renders its content 
   *)
  Tabs.render url
    [ "profile",   show_user_profile person ;
      "countdown", show_birthday_countdown person ]

Obviously, a lot of functions called to render the contents of that tab will have to handle exceptions when the user is deceased — but the sane thing to do would be to hide the tab in the first place. If you don’t try to render the tab contents, no errors will happen while rendering it… The problem, of course, is that if we check whether the user is alive outside the tab contents (in order to decide if the tab is present) we still have to check whether the user is alive inside the tab contents, even though we know that the tab contents would not have been rendered if this were not the case:

let show_user_profile person url = (* ... *)

let show_birthday_countdown person url =
  printf "%d minutes left to age %d"
    (get_minutes_to_birthday person)
    (match get_age person with `age a -> a | `person_is_dead -> (* Should never happen! *))

let profile_page person url =
  (* This renders all available tabs, then checks which one is 
   * active based on url and renders its content (default is the first one) 
   *)
  Tabs.render url
    [ "profile", show_user_profile person ]
    @ (if Person.is_dead person then []
       else [ "countdown", show_birthday_countdown person ])

Above, an if-then-else makes sure that show_birthday_countdown will only ever be called if the person is not dead (otherwise the tab is not available and the profile tab is shown instead). However, the show_birthday_countdown function does not know that, which means that pattern matching must still be used even though the error is known not to happen — and I hate “should never happen” comments in code. Should another programmer reuse the birthday countdown in another context where the unwritten assumption that the person is alive is not verified, the compiler will not be able to detect it, and the “should never happen” will happen. Constructs like the above should be avoided like the plague. Instead, the unwritten assumption should be written into a type.

Let’s build a different type that is known to be a living person:

module AlivePerson : sig
  type t = private Person.t
  val is_alive : Person.t -> t option
  val get_age  : t -> int
end = struct

  type t = Person.t

  let is_alive person =
    if Person.is_dead person then None
    else Some person

  let get_age person =
    Date.subtract Date.today (Person.birth_date person)

end

How does this work? First, we define a private type — this means that within the definition of the AlivePerson module, AlivePerson.t and Person.t are the same type, but outside, they are different and incompatible types. Being incompatible means that we need to define a function that creates an AlivePerson.t from a Person.t — this is what AlivePerson.is_alive does : if the person is alive, it is returned with type AlivePerson.t, and otherwise no value is returned. This proves that only a Person.t who is not dead can be turned into an AlivePerson.t. Finally, we define the AlivePerson.get_age function which, on living persons, always returns the age without checking for them being alive.

Next up, we must re-define the original get-age function, because we don’t want to repeat ourselves: only write the age calculation code once! The good news is that the AlivePerson module provides everything we need to do this:

let get_age person =
  match AlivePerson.is_alive person with
    | None       -> `person_is_dead
    | Some alive -> `age (AlivePerson.get_age alive)

The function signature remains the same, so it’s a safe bet to say that the behavior did not change (and unit tests should make sure that it did not). Then, we can finally rewrite the offending tab-rendering code so that the countdown tab expects an alive person as an argument :

let show_birthday_countdown alive url =
  printf "%d minutes left to age %d"
    (get_minutes_to_birthday (alive :> Person.t))
    (AlivePerson.get_age alive)

let profile_page person url =
  Tabs.render url
    [ "profile", show_user_profile person ]
    @ (match AlivePerson.is_alive person with
       | None       -> []
       | Some alive -> [ "countdown", show_birthday_countdown alive ])

No compiler error occurs, and there is no more “should never happen” case in the first function. Also, should that function be re-used in a context where the assumption about the person being alive is not available, the compiler will issue an error (this value has type Profile.t but a value was expected of type AliveProfile.t) because type inference has determined (based on the call to AlivePerson.get_age) that alive is of type AlivePerson.t! Your unwritten assumption has been detected and checked by the compiler.

In Conclusion

In this article, I demonstrated how to turn exceptions into compiler-checked return values, this turning the compiler into a valuable ally that detects any locations where the addition of a new error might require altering existing functionality. I also illustrated how this enables the programmer to pre-empt the possibility of exceptions by injecting a compiler-verified proof that «this will not throw an exception» into a new module. The consequence of these coding practices is fewer mishandled exceptional situations, the ability to detect all consequences of a new kind of error, and a clean documentation of both error types and assumptions about what errors might or might not happen in a given piece of code.

Which, I believe, leads to better code and happier developers. What do you think?