Result types are roughly equivalent to exceptions.

This article is part of a a series about software design isomorphisms, although naming this one an isomorphism is a stretch. A real isomorphism is when a lossless translation exists between two or more different representations. This article series has already shown a few examples that fit the definition better than what the present article will manage.

The reader, I hope, will bear with me. The overall series of software design isomorphisms establishes a theme, and even when a topic doesn’t fit the definition to a T, I find that it harmonizes well enough that it still belongs.

In short, the claim made here is that ‘Result’ (or Either) types are equivalent to exceptions.

I’ve deliberately drawn the arrows in such a way that they fade or wash out as they approach their target. My intent is to suggest that there is some loss of information. We may consider exceptions and result types to be roughly equivalent, but they do, in general, have different semantics. The exact semantics are language-dependent, but most languages tend to align with each other when it comes to exceptions. If they have exceptions at all.

Checked exceptions #

As far as I’m aware, the language where exceptions and results are most similar may be Java, which has checked exceptions. This means that a method may declare that it throws certain exceptions. Any callers must either handle all declared exceptions, or rethrow them, thereby transitively declare to their callers that they must expect certain exceptions to be thrown.

Imagine, for example, that you want to create a library of basic statistical calculations. You may start out with this variation of mean:

public double mean(double[] values) {
if (values == null || values.length == 0) {
throw new IllegalArgumentException(
"The parameter 'values' must not be null or empty.");
}
double sum = 0;
for (double value : values) {
sum += value;
}
return sum / values.length;
}

Since it’s impossible to calculate the mean for an empty data set, this method throws an exception. If we had omitted the Guard Clause, the method would have returned NaN, a questionable language design choice, if you ask me.

One would think that you could add throws IllegalArgumentException to the method declaration in order to force callers to deal with the problem, but alas, IllegalArgumentException is a RuntimeException, so no caller is forced to deal with this exception, after all.

Purely for the sake of argument, we may introduce a special StatisticsException class as a checked exception, and change the mean method to this variation:

public static double mean(double[] values) throws StatisticsException {
if (values == null || values.length == 0) {
throw new StatisticsException(
"The parameter 'values' must not be null or empty.");
}
double sum = 0;
for (double value : values) {
sum += value;
}
return sum / values.length;
}

Since the new StatisticsException class is a checked exception, callers must handle that exception, or declare that they themselves throw that exception type. Even unit tests have to do that:

@Test void meanOfOneValueIsTheValueItself() throws StatisticsException {
double actual = Statistics.mean(new double[] { 42.0 });
assertEquals(42.0, actual);
}

Instead of ‘rethrowing’ checked exceptions, you may also handle them, if you can.

Handling checked exceptions #

If you have a sensible way to deal with error values, you may handle checked exceptions. Let’s assume, mostly to have an example to look at, that we also need a function to calculate the empirical variance of a data set. Furthermore, for the sole benefit of the example, let’s handwave and say that if the data set is empty, this means that the variance is zero. (I do understand that that’s not how variance is defined, but work with me: It’s only for the sake of the example.)

public static double variance(double[] values) {
try {
double mean = mean(values);
double sumOfSquares = 0;
for (double value : values) {
double deviation = value - mean;
sumOfSquares += deviation * deviation;
}
return sumOfSquares / values.length;
} catch (StatisticsException e) {
return 0;
}
}

Since the variance function handles StatisticsExceptions in a try/catch construction, the function doesn’t throw that exception, and therefore doesn’t have to declare that it throws anything. To belabour the obvious: The method is not adorned with any throws StatisticsException declaration.

Refactoring to Result values #

The claim in this article is that throwing exceptions is sufficiently equivalent to returning Result values that it warrants investigation. As far as I can tell, Java doesn’t come with any built-in Result type (and neither does C#), mostly, it seems, because Result values seem rather redundant in a language with checked exceptions.

Still, imagine that we define a Church-encoded Either, but call it Result<Succ, Fail>. You can now refactor mean to return a Result value:

public static Result<Double, StatisticsException> mean(double[] values) {
if (values == null || values.length == 0) {
return Result.failure(new StatisticsException(
"The parameter 'values' must not be null or empty."));
}
double sum = 0;
for (double value : values) {
sum += value;
}
return Result.success(sum / values.length);
}

In order to make the change as understandable as possible, I’ve only changed the function to return a Result value, while most other design choices remain as before. Particularly, the failure case contains StatisticsException, although as a general rule, I’d consider that an anti-pattern: You’re better off using exceptions if exceptions are what your are dealing with.

That said, the above variation of mean no longer has to declare that it throws StatisticsException, because it implicitly does that by its static return type.

Furthermore, variance can still handle both success and failure cases with match:

public static double variance(double[] values) {
return mean(values).match(
mean -> {
double sumOfSquares = 0;
for (double value : values) {
double deviation = value - mean;
sumOfSquares += deviation * deviation;
}
return sumOfSquares / values.length;
},
error -> 0.0
);
}

Just like try/catch enables you to ‘escape’ having to propagate a checked exception, match allows you to handle both cases of a sum type in order to instead return an ‘unwrapped’ value, like a double.

Not a true isomorphism #

Some languages (e.g. F# and Haskell) already have built-in Result types (although they may instead be called Either). In other languages, you can either find a reusable library that provides such a type, or you can add one yourself.

Once you have a Result type, you can always refactor exception-throwing code to Result-returning code. This applies even if the language in question doesn’t have checked exceptions. In fact, I’ve mostly performed this manoeuvre in C#, which doesn’t have checked exceptions.

Most mainstream languages also support exceptions, so if you have a Result-valued method, you can also refactor the ‘other way’. For the above statistics example, you simply read the examples from bottom toward the top.

Because it’s possible to go back and forth like that, this relationship looks like a software design isomorphism. It’s not quite, however, since information is lost in both directions.

When you refactor from throwing an exception to returning a Result value, you lose the stack trace embedded in the exception. Additionally, languages that support exceptions have very specific semantics for that language construct. Specifically, an unhandled exception crashes its program, and although this may look catastrophic, it usually happens in an orderly way. The compiler or language runtime makes sure that the process exits with a proper error code. Usually, an unhandled exception is communicated to the operating system, which logs the error, including the stack trace. All of this happens automatically.

As Eirik Tsarpalis points out, you lose all of this ‘convenience’ if you instead use Result values. A Result is just another data structure, and the semantics associated with failure cases are entirely your responsibility. If you need an ‘unhandled’ failure case to crash the program, you must explicitly write code to make the program return an error code to the operating system.

So why would you ever want to use Result types? Because you also, typically, lose information going from Result-valued operations to throwing exceptions.

Most importantly, you lose static type information about error conditions. Java is the odd man out in this respect, since checked exceptions actually do statically advertise to callers the error cases with which they must deal. Even so, in the first example, above, IllegalArgumentException is not part of the statically-typed method signature, since IllegalArgumentException is not a checked exception. Consequently, I had to invent the custom StatisticsException to make the example work. Other languages don’t support checked exceptions, so there, a compiler or static analyser can’t help you identify whether or not you’ve dealt with all error cases.

Thus, in statically typed languages, a Result value contains information about error cases. A compiler or static analyser can check whether you’ve dealt with all possible errors. If you refactor to throwing exceptions, this information is lost.

The bottom line is that you can refactor from exceptions to Results, or from Results to exceptions. As far as I can tell, these refactorings are always possible, but you gain and lose some capabilities in both directions.

Other languages #

So far, I’ve only shown a single example in Java. You can, however, easily do the same exercise in other languages that support exceptions. My article Non-exceptional averages goes over some of the same ground in C#, and Conservative codomain conjecture expands on the average example in both C# and F#.

You can even implement Result types in Python; the reusable library returns, for example, comes with Maybe and Result. Given that Python is fundamentally dynamically typed, however, I’m not sure I’m convinced of the utility of that.

At the other extreme, Haskell idiomatically uses Either for most error handling. Even so, the language also has exceptions, and even if some may think that they’re mostly present for historical reasons, they’re still used in modern Haskell code to model predictable errors that you probably can’t handle, such as various IO-related problems: The file is gone, the network is down, the database is not responding, etc.

Finally, we should note that the similarity between exceptions and Result values depends on the language in question. Some languages don’t support parametric polymorphism (AKA generics), and while I haven’t tried, I’d expect the utility of Result values to be limited in those cases. On the other hand, some languages don’t have exceptions, C being perhaps the most notable example.

Conclusion #

All programs can fail. Over the decades, various languages have had different approaches to error handling. Exceptions, including mechanisms for throwing and catching them, is perhaps the most common. Another strategy is to rely on Result values. In their given contexts, each offer benefits and drawbacks.

In many languages, you have a choice of both. In Haskell, Results (Either) is the idiomatic solution, but exceptions are still possible. In C-like languages, ironically, exceptions are the norm, but in many (like Java and C#) you can bolt on Results if you so decide, although it’s likely to alienate some developers. In a language like F#, both options are present at an almost equal proportion. I’d consider it idiomatic to use Result in ‘native’ F# code, while when interoperating with the rest of the .NET ecosystem (which is almost exclusively written in C#) it may be more prudent to just stick to exceptions.

In those languages where you have both options, you can go back and forth between exceptions and Result values. Since you can refactor both ways, this relationship looks like a software design isomorphism. It isn’t, though. There are differences in language semantics between the two, so a choice of one or the other has consequences. Recall, however, as Sartre said, not making a choice is also making a choice.

Next: Builder isomorphisms.