Why do “checked exceptions”, i.e., “value-or-error return values”, work well in Rust and Go but not in Java?

Question

Java has "checked exceptions", which force the caller of the method to either handle an exception or to rethrow it, e.g.

// requires ParseException to be handled or rethrown
int i = NumberFormat.getIntegerInstance().parse("42").intValue();

Other, more recent languages such as Go and Rust use multiple return values instead:

i, err := strconv.Atoi("42")    // Go

match "42".parse::<i32>() {     // Rust
  Ok(n) => do_something_with(n),
  Err(e) => ...,
}

The underlying concept is similar: The caller of the method has to do something about potential errors and can't just let them "bubble up the stack trace" by default (as would be the case with non-checked exceptions). From some points of view, checked exceptions can be seen as syntactic sugar for alternative return values.

However, checked exceptions are widely disliked. The C# designers made the deliberate decision to not have them. On the other hand, Go and Rust and extremely popular.

---

Why did this concept (see the bolded sentence above) fail in Java but succeed in Go and Rust? What mistakes did the Java designers make that the Go and Rust designers didn't? And what can we learn about programming language design from that?

Answer 1

From a scientific point of view, checked exceptions can be seen as alternative return values, e.g.

Exactly. They can be seen that way, and they should be but they aren't.

Using an Error type like is common in Rust, Elm, Haskell, and in some sub-communities in Scala or a special error value as in Go is just an alternative return value indicated in the type system. A checked exception is like an alternative return value, but it doesn't use the normal way of returning values, it is a completely separate, very different way of "returning values". It also sits outside of the type system, and bolts on a completely separate "checked exception" system onto the type system.

But most importantly, it is not just an alternative return value, it is also an alternative control flow.

Another problem with the specific way checked exceptions are implemented in Java, is that they are anti-modular. That is, however, not a fundamental problem of checked exceptions, unlike the ones I mentioned above. There is an idea of Modular Anchored Exceptions, for example, where you can specify something like

int foo() throws like bar { return bar(); }

And you don't have to know (and leak!) which precise exceptions bar can throw. You can even do something like throws like bar except ArrayOutOfBoundsException when you are handling some errors yourself.

Answer 2

Disclaimer: This will, to a degree, be my own personal take on the problem. I love programming language design, I've thought, read, and discussed a lot of about PL design in general, and the hard topic of errors in particular. This gives me some experience, and also an appreciation that beyond objective factors, there is a lot of subjectivity at play. I will try to separate objective from subjective, but I am biased and therefore may err.

TL;DR: Checked Exceptions are poorly integrated in Java.

---

However, checked exceptions are widely disliked. The C# designers made the deliberate decision to not have them.

Be careful about generalizations.

The current incarnation of Checked Exceptions in Java is widely disliked. The reason for the dislike, however, may be either Checked Exceptions themselves, OR the current incarnation in Java. And possibly a mix of both.

---

Poor integration

As a simple example, look at the interface of Stream: if you want to use filter, or map, your predicates cannot throw a Checked Exception.

The underlying issue here is that the Java language offers no way to easily handle, and manipulate, lists of Checked Exceptions in a generic context. At the end of the day, I'd like to be able to write:

class Foo<T>
{
    <R, ME..., FE...> R transform(
        Function<? extends T, ? extends R, throws ME...> mapper,
        Predicate<? extends R, throws FE...> filter
    )
        throws (ME..., FE..., -BarException)
    {
        try
        {
             return filter(mapper(this.element));
        }
        catch (BarException e)
        {
             return default();
        }
    }
}

And I can't.

Due to the rise of Generics, and of Functional Programming idioms such as Stream, Checked Exceptions have become increasingly more inconvenient as time passes.

---

Exceptions

We could stop at poor integration and call it a day, concluding that Checked Exceptions in and out of themselves are perfectly fine, and Java just botched it.

A closer look, however, reveals that Exceptions themselves are part of the issue in the first place. Specifically, the main problem of exceptions is that they are not return types.

One of the advantage that Rust or Haskell have in using Return Types to signal Errors is that any advance that allows better compile-time manipulation of the Return Types (meta-programming) simultaneously grants better compile-time manipulation of Error Specifications in function signatures.

On the other hand, using Exceptions means that efforts must be, to a degree, duplicated between meta-programming on Return Types and meta-programming on Exception Specifications.

This comes to a head in Java because Java doesn't support Variadic Generics, but supports Variadic Exception Specifications. It makes it even more complicated to provide proper meta-programming facilities for the Exception Specifications... and is likely the root cause of Java designers having seemingly thrown their hands up.

A language could choose to provide proper meta-programming facilities to manipulate Exception Specifications in signature, and in that case Checked Exceptions would feel first class. Yet, even then, I expect that it would still not be as convenient as manipulating Return Types, because you would then need to manipulate both Return Types and Exception Specifications, leading to extra work -- as demonstrated in computation of noexcept clauses in C++.

---

Conclusion

The rise of Generics -- notably for Functional Programming -- has led to a rise of Meta Programming which requires manipulating function signatures at compile-time.

Exception Specifications are not as convenient to manipulate in function signatures -- at best they double the work, as Return Types must always be manipulated regardless -- and may not support manipulation at all as it requires extra-work on the part of language designers and language implementers.

Checked Exceptions in Java require Exception Specifications in a language which does not allow manipulating them via meta-programming, making their use awkward to impossible in Generic code, which is increasingly prevalent.

By comparison, Rust's Result type benefits from all the meta-programming machinery available in Rust in general -- without extra expense from designers, implementers, or users -- and therefore offers a much smoother experience.

Answer 3

Checked exceptions can't be treated as just another part of the expression. They must be handled out of line.

With an error return value, you can write a function that converts error values to a default value, for example. Something like this (even if the variant type has no getOrDefault method):

setNumber(getOrDefault(parseInt(stringValue), 0));

With checked exceptions, you have to write this:

int parsedNumber;
try {
    parsedNumber = parseInt(stringValue);
} catch(NumberFormatException exc) {
    parsedNumber = 0;
}
setNumber(parsedNumber);

which is much less wieldy and you can't abstract it. Sure, you could write a parseIntOrDefault function, but you'd also have to write a separate parseLongOrDefault, parseFloatOrDefault, etc. There's no way to write a general "convert parse error to default value" function.

And no, you can't put setNumber inside the try block, because what if setNumber can also throw a NumberFormatException?

Answer 4

There are three parts to error code:

1. Code that generates the errors.
2. Code that handles the errors.
3. Code that just propagates the errors from part 1 to part 2.

Most programmers don't give part 3 much thought, because most "enterprise" languages use unchecked exceptions where the part 3 code is essentially invisible. In error propagating code, you want to be aware that there are errors potentially propagating through your code, because someone in the call stack above you is going to have to handle those errors.

However, the propagating code doesn't care what those errors are. When new kinds of errors get thrown, or some kinds of errors start being handled further down in the stack, you don't care. You just pass along whatever you get.

The problem with checked exceptions is they force you to care. If I want to start throwing a checked exception, I have to change the type signature of every single propagating function, breaking compatibility. Some of those functions might be in code I have no control over.

In SOLID terms, you're breaking the open-closed principle in a big way, because you can't add a new function at the bottom of the stack without modifying all the propagating functions in the middle.

Go and Rust force you to know the potential for an error exists, but if you are just propagating the error, you don't have to precisely know every potential value it might take.

Answer 5

There are some good points made in other answers, but I feel each picks out a different aspect, so I'm going to try to bring them together.

Checked vs unchecked errors

The idea of statically checking code is to make "bad" programs impossible to write. In other words, it places constraints on what the programmer can do. Those constraints have a natural tendency to conflict with the programmer's main goal: to efficiently express a desired behaviour.

Language designers can do two things to make this less "painful" for the programmer:

• Relax the constraints in certain situations, e.g. allowing some categories of errors to go unchecked
• Provide expressive abstractions which work well alongside the constraints, e.g. short-hand syntaxes for passing an error up the stack

Whether a particular language provides a "good" set of compromises and abstractions is a matter of opinion.

Returning vs throwing

Exceptions are theoretically equivalent to additional return values only in the same sense that a foreach loop is theoretically equivalent to a while loop: they provide a different developer experience.

The primary difference is that exceptions introduce an additional control flow to the program - after a "throw" statement, control automatically jumps to the appropriate "catch" block, rather than the context the subroutine was called from.

This makes some things easier to express, such as a sequence of dependent statements, or elements within an expression, where you want to abort the sequence or expression as soon as any error is encountered, e.g.:

try {
   doSomething( 
       convertToUpperCase(functionThatMightError()),
       anotherFunctionThatMightError() + someOtherValue
   );
} catch(error foo) {
   doSomethingElse();
}

However, it makes other things more difficult to express, such as substituting a default value into an expression in case of error:

foo = functionThatMightError() -> ifErrorThen(fallbackValue);

Because exceptions always cause a jump in control, there has to be a separate statement to jump to:

try {
   foo = functionThatMightError();
} catch(error e) {
   foo = fallbackValue;
}

It would be possible for a language to help the programmer express this, with some kind of inline catch which meant control didn't jump; as far as I know, Java does not. It is also possible for languages without exceptions to help the programmer express the "abort-on-error" case, e.g. Haskell's do notation.

Checked exceptions vs static types

Because throwing and returning are not interchangeable, checked exceptions need to track extra information for each function: rather than { input types, return type } the signature now includes { input types, return type, possible exceptions }. Tools the language provides to do expressive things with return type don't automatically apply to possible exceptions.

For instance, for the function map( someList, someTransform ), the language might provide tools to specify that the return type of map is related to the type of someTransform:

map( List<T> someList, Transform<T,U> someTransform ): List<U>

With checked exceptions, the language now also needs to allow the programmer to express how the possible exceptions thrown by map relate to those thrown from someTransform.

If the language does provide a syntax to express this, the programmer now needs to understand and apply it.

Checked exceptions in Java specifically

Some of the common complaints about checked exceptions in Java are the result of design decisions or common practices in that language.

For instance:

• The original standard library in Java used checked exceptions heavily, where it might have been more useful to mix it with other types of error handling.
• Exceptions in Java tend to be of very specific types, leading to long names, and long lists of possible cases in in throws clauses. Some more recent languages make less use of sub-typing for their errors (whether thrown or returned).
• Java does support leaving some exceptions unchecked, but this is baked into the single-inheritance type hierarchy, rather than on a per-class or even per-instance basis.
• Java exceptions always capture a stack trace, which is relatively expensive, and not necessary if the error is handled immediately. This is a common design for exceptions, but not actually inevitable.

Answer 6

checked exceptions can be seen as syntactic sugar for alternative return values

This is the modern perspective on this language feature, but the feature was initially intended and used for a different purpose, at which it failed.

Checked exceptions were added to the Java language before its initial release back in 1996. Back then, Java aspired to be a more dynamic and robust C++. Back then, exception support in C++ was rather new and controversial, but the Java designers felt that exceptions were more robust than returning error codes (because it is harder to accidentally ignore an exception that an error code), and made exceptions an integral part of the language. However, since C++ exception support was so new, some aspects of its exception support were still rather experimental at the time, and one such aspect were "exception specifications". Since the Java team could not wait, they opted to finish were that was going, and invented checked exceptions.

And so they had a new tool that they felt revolutionized error handling in software, and used it liberally when writing the first version of the Java API, communicating nearly all error conditions using checked exceptions - and since Java aspired to be a robust language, they were unusually diligent in communicating possible error conditions.

Together, this meant that not only the Java API was fussy about exceptions, but it also forced this onto its callers. For instance, when you do monitor.wait() you have to handle a checked InterruptedException, even when you know that nobody is interrupting threads. Or when you do new InputStreamReader(file, "ascii"), you have to handle an UnsupportedEncodingException, even though ASCII is guaranteed to be supported by the Java spec.

That is, the early Java API overused checked exceptions to communicate error conditions that callers often don't care about.

The pain of this is still felt today because there is no way to remove a checked exception from a throws clause without changing calling code or making the exception type unchecked by changing its class hierarchy, which is often impossible because this single hierarchy is the only way to catch a group of exception types.

That is, the major pain point of checked exceptions is not that checked exceptions are supported, but their overuse by the Java API, which can not be corrected without breaking API compatibility.

But even if that weren't the case, returning union types is strictly superior to checked exceptions for the following reasons:

• checked exceptions are exceptions. For instance, their construction captures a stack trace, which is quite expensive (you can suppress this if all super classes collaborate to use the 4 argument constructor of Throwable, but doing so might surprise your callers ...)

• the decision whether the exception is checked depends on the class hierarchy. This means you can't throw the same exception checked from one method, but unchecked from another. It also means that callers can't catch related exceptions of different checkedness as a group.

• since exceptions are classes they need globally unique names, which tend to be longer than method-specific ones (compare NoSuchElementException to none). Also, classes take more effort to declare.

• exceptions don't play nice with scoping rules, making their use quite verbose. For instance, we have to write:

  ReallyLongType<With, Many, Generics> result;
  try {
      result = foo();
  } catch (ReallyLongTypeCurrentlyNotAvailableException e) {
      result = defaultValue;
  }
  
  result.bar();
  

  rather than:

  var result = foo() or defaultValue;
  

And that's why, in modern java code, we often prefer union types over checked exceptions. For instance, the above can be written as

    var result = foo().orElse(defaultValue); 

if foo returns an Optional.

And what can we learn about programming language design from that?

• be mindful of the different maturity levels of different language features, and have a process for incubating new language features that allows you to undo mistakes and extensively test the new feature in real world use cases before committing to its perpetual support (I think TC39, which evolves EcmaScript, does this really well).
• that some error codes can be replaced by exceptions does not imply that all error codes should be.

Answer 7

Short answer: It is too easy to just "try catch swallow" everything in java*. Where in Rust and Go, it's much easier to just write good error control code 'correctly', and make it hard to do poorly. i.e., "Falling into the pit of success" programming paradigm.

I strongly suggest you read Joe Duffy's blog on error handling strategies, which were looked at while developing the Midori OS

---

* Perhaps since java is a common University language, this "try catch swallow" 'strategy, is a bad habit picked up as a student; whose biggest problem was just getting the code to compile, then maybe actually putting out the correct output. Maintainability and code quality were not their biggest concerns.

Answer 8

The problem with using always the return value approach is that often the developers end up mixing business logic and error handling. Beyond return values, error handling could be about:

1. Resource handling, closing access to files or database connections, even though this point was later addressed with the construct try/with resource
2. Transaction handling. When multiple services and databases are involved rolling back a transaction might not be straightforward.
3. Detailed logging. sending messages to external audit systems, bug reports.
4. Rather than an external audit system there might be a full separate error handling platform notified by messages sent in the catch block.
5. Eventual retry. The exception might have been caused by a temporary condition like a timeout or a missing network.

Many of those points were specific to enterprise environments, developers of desktop application might simply complain about the restrictions without thinking about it. But Java is designed for a quite different environment.

Answer 9

Awkward typing

The type winds up being T with a type union of A, B, C.

This is an odd type that doesn't work best with other things, for example

Generics

There isn't a good way to do a generic with variadic check exception.

Classes

In Java, every exception must extend Throwable with a stack trace.

---

You could invent solutions to these, and you'd likely wind up with something pretty close to Go/Rust.