Checked exceptions

Florian Weimer fw at
Thu Oct 17 21:33:08 UTC 2019

* Aaron Scott-Boddendijk:

> I like Rusts model. Returning Result<T, E> which is either Ok(T) or Err(E).

Please keep in mind that Rust only does this for a subset of errors.
That's why I think the Rust experience can be quite misleading.

Furthermore, result handling in Rust faces some of the same challenges
as checked exceptions.  The current type system requires duplicating
functionality for dealing with Result types and non-Result types,
particularly related to iteration (where you want to stop on the first


The misleading part is this: I haven't checked this recently, but not
too long ago, things that are VirtualMachineErrors in Java (and thus
unchecked) tend to trigger irrecoverable process termination in Rust
(such as stack overflows and out-of-memory conditions).  I know that,
VirtualMachineErrors are not recoverable in Java, either (you are
supposed to restart the VM), but most services get away without doing
that, so adopting the Rust model would be rather drastic.

But in Rust, integer division by zero, array indexing errors, integer
arithmetic overflow in debug mode, and test failures in the test
framework (!)  trigger regular exceptions (called panics), which can
be caught and handled.  These exceptions are not reflected in function
types (pretty much like unchecked exceptions in Java).

(As a system programming language for GNU/Linux, some level of
exception support is mandatory because even GNU C supports exceptions
with DWARF-based unwinding on that platform, and functionality like
POSIX thread cancellation depends on it, whether you like it or not.
However, the Rust programmers are still undecided on this issue.  But
as I said, their test framework depends on exceptions.)

As far as I know, general-purpose programming languages which
completely lack (unchecked) exceptions with stack unwinding are quite
rare today (on GNU/Linux).

More information about the jdk-dev mailing list