Unchecked Java: Say goodbye to checked exceptions (opens in new tab)

Yep. This is similar to a viewpoint by Anders Hejlsberg and many on the C# team at the time: https://www.artima.com/articles/the-trouble-with-checked-exc...

> You see programmers picking up new APIs that have all these throws clauses, and then you see how convoluted their code gets, and you realize the checked exceptions aren't helping them any.

And he goes on to elaborate on how this gets more complicated when versioning is introduced into the mix.

> That bug should have been caught by tests, code reviews and good communication.

There's a reason we have compile-time checks. If you think compile-time checks should be replaced with additional tests, code reviews and good communication, then you want a scripting language, not a compiled language.

You do not wrap checked exceptions in an unchecked one... unless you are a really bad Java programmer.

If the Future, Executor, Optional, Streams, etc played nice with checked exceptions it would probably be different. Right now at some point you do have to wrap it into an unchecked exception.

Let's be really honest

  try {
    theUpdatedFunction();
  } catch (MyNewCheckedException e) {
    logger.warn("Whoopsie doopsie", e);
    throw new SomeUncheckedException(e.message);
  }

There's a special place in Hell for these people, but at least they'll get to see all of their friends again.

>The code still breaks the same way

That's not a valid argument. This is an explicit decision, so they reap what they sowed.

One could just as well make the same argument for Optionals, that you can just do:

  let val = foo.unwrap();

Or, worse, you're reviewing a large diff, see the logger statement but don't notice that the junior whose code you're reviewing forgot to rethrow. Now you've accidentally entered uncharted territory where way more scarier things can happen to your application than just crashing. Of course this shouldn't happen, but it does.

> That bug should have been caught by tests, code reviews and good communication

This is such an unproductive cop out response. The problem could be completely solved by functional error handling, which leverages the compiler to force you to handle exactly the errors than can happen, no more, no less.

> throw new SomeUncheckedException("Something failed, idk", e)

Who does that? It looks like an anti-pattern.

From a type theory perspective, an exception is another type of return value that a function can have, and not documenting those in the function signature is absurd.

I have seen libraries that make network calls that do the following:

* Throw an exception on certain types of network errors * Return an HTTP error code for other types of network errors * Return an object with error set to true and an error string for other types of network errors

NONE of those was documented, it is crazy. This actually bite me in prod when an undocumented exception that we hadn't seen in over a year of uptime was finally thrown. I had to look at network logs to try and figure out why it was being thrown (no checked exceptions in JS!), which itself is absurd.

That's how you do it in C#... See InnerException [1]. What a good programmer would do is to throw a new exception, and fix the callers to handle the new error.

https://learn.microsoft.com/en-us/dotnet/api/system.exceptio...

You’re both right and wrong. Checked exceptions slow down development, make code ugly and in my theoretical opinion are an anti-pattern that should never be used.

However in small to mid sized enterprise software companies with average developer talent it’s important to keep boundaries (and blame) clear.

In the scenario in question, the CTO will blame OP and make them work the weekend to diagnose/fix it, so wrapping the other exception and throwing their own SomeModuleException will cover their ass.

Java is popular for all the wrong reasons. Believe it or not there are hundreds of such companies in the US alone heavily using Java in this manner and then there is the whole offshore development segment.

Checked exceptions are just another return type with a weird syntax. It's not that Rust's result type is more versatile, it's just less syntax to accomplish what works out to be the same thing.

> There is no magic language trick that can prevent you from having to rerun all tests for your software if you update a dependency. Pretty much period.

Of course, but having a checked exception (even better, having the errors be part of the return type via Result<T, E> or Option<T>) solved an entire class of problem. Doesn't mean that there aren't others of course. But surely this is a win?

>inb4 it makes the code very complex with nested return type Result<Result<Result<T, FileNotFoundError>,ReadError>, ParseError>

Then it was just hidden from you before. The complexity had always been there, it just never occurred to you that it can happen.

If someone added an extra parameter to a function you're calling, when would you want to be alerted about it? At compile time? Or when you rerun all the tests?

Hopefully, your answer is compile time. If so can you now understand why you would want to be alerted about a new exception getting thrown at compile-time as well?

Not true. Exception hierarchies solve this problem.

So you mean, catch the root Exception class. Pretty much everyone agrees that's a bad idea, C# and Java both advice against that. But in the case of C# you have to do it, to avoid crashing all the time, because there's no reliable way to determine what exceptions can be expected. In Java the compiler will tell you what exceptions can be expected, but in C# you have to rely on documentation which is not reliable.

And do what with it? If you don't know what it really is, the best thing is to let things fail fast and the standard logging to kick in and record all the details of the crash.

Certainly you can intentionally break it, but then that's on you.

> Checked exceptions are exactly analogous of Result/Either types.

No, they aren't.

They are not compositional. You may want to write `f(g())` but there's no way to write the parameter type of `f` to make this work (in Java). That's because checked exceptions are an "effect" that would require extending the Java type system.

To my mind the big issue with existing examples of checked exceptions is that the language to talk about the exceptions is woefully inadequate, so it stops you from writing things that would be useful while dealing correctly with exceptions. The go-to example is a map function, which we should be able to declare as throwing anything that might be thrown by its argument. Without that we need to either say that map might throw anything and then handle cases that actually can't happen, suppress/collect exceptions inside map, or suppress/collect errors inside the functions we're passing to map, all of which add boilerplate and some of which add imprecision or incorrectness. It would also be good to be able to state that a function handles some exceptions if they are thrown by its argument. And all of this should be able to be composed arbitrarily. And... somehow not be too complicated. For usability, it should probably also be possible to infer what's thrown for functions that are not part of an external API.

No, unfortunately they are not. The problem is not with checked exceptions themselves, but with the other type of exceptions in Java.

In languages that rely on Result/Either for error handling, you've got two types of errors: Typed errors (Result/Either) and untyped panics. Typed errors are supposed to be handled, possibly based on their type, while panics can be recovered from ("catched") but these are serious, unexpected errors and you're not supposed to try to handle them based on their type. Since typed errors generally need to be handled explicitly while untyped errors are unexpected, typed errors are always checked (you can't skip handling them), while untyped errors are unchecked (implicitly propagated up the stack if you don't do anything to catch them).

Java has three types of errors:

1. Checked errors, a.k.a. checked exceptions: (exceptions that inherit from Exception, but not from RuntimeException). 2. Unchecked application errors: exceptions that inherit from RuntimeException. 3. Unchecked fatal errors: exceptions that inherit from Error.

These three kinds of errors live in a confusing class hierarchy, with Throwable covering all of them and unchecked application errors being a special case of checked application errors.

Like everything else designed in the early Java days, it shows an unhealthy obsession with deep class hierarchies (and gratuitous mutability, check out initCause()!). And this is what destroyed the utility of checked exceptions in Java in my opinion.

Consider the following example: We have a purchase() function which can return one of the following errors:

- InsufficientAccountBalance - InvalidPaymentMethod - TransactionBlocked - ServerError - etc.

You want to handle InsufficientAccountBalance by automatically topping up the user's balance if they have auto top-up configured, so you're going to have to catch this error, while letting the rest of the errors propagate up the stack, so an error message could be displayed to the user.

In Rust, you would do something like this:

  account.purchase(request).map_err(|err| match err {
    PurchaseError.InsufficientAccountBalance(available, required) => {
      account.auto_top_up(required - available)?
      account.purchase(request)
    }
    _ => err // Do not handle other error, just let them propagate
  })

In Java, you would generally do the following:

  try {
    account.purchase(request);
  } catch (InsufficientAccountBalance e) {
    account.auto_top_up(e.requiredAmount - e.availableAmount);
    account.purchase(request);
  } catch (Exception e) {
    // We need to catch and wrap all other checked exception types here
    // or the compiler would fail
    throw new WrappedPurchaseException(e);
  }

The "catch (Exception e)" clause doesn't just catch checked exceptions now - it catches every type of exception, and it has to wrap it in another type! Of course, you can also specify every kind of checked exception explicitly, but this is way too tedious and what you get in practice is that most code will just catch a generic Exception (or worse - Throwable!) and wrap that exception or handle it the same way, regardless if it was a NullPointerException caused by a bug in code, an invalid credit card number.

The worst problem of all is that once developers get used to write "catch (Exception e)" everywhere, they start doubting the values of checked exceptions: after all, most of their try clauses seem to have a generic "catch (Exception e)", so does it really matter at all of they're using checked exceptions?

This is the reality. Checked exceptions failed in Java. Most Java developers see them as nothing more than a nuisance and look for ways to bypass them. That does not necessarily mean that the concept of checked exception as a language level facility for errors has failed, but it certainly failed the way it has been implemented in Java.

> And I guess this is precisely why so many developers hate them; they don't like the extra work they have to do to catch all those edge conditions. This is why we see so many empty catch blocks or upcasting to Exception or even Throwable; it is laziness.

Good developers should be lazy. Checked exceptions require you to do a bunch of cumbersome ceremony that makes your code unreadable, for what should be (and is, with Either or equivalent) at most a couple of symbols; no wonder developers hate that.

> I would also argue that checked exceptions are no more complex than Eithers, Try or Applicatives.

You'd be wrong. Checked exceptions as implemented in Java require two keywords of their own (throw and catch), a special change to method signatures (throws), a unique new kind of expression for multi-catch (|), a unique new kind of type for things caught in multi-catches, and special support in every other new language feature (e.g. Futures have a whole bunch of extra code to deal with exceptions). Eithers can literally be a regular class that you could write yourself using ordinary language features. A small piece of syntax sugar (something like "do notation", "for/yield comprehensions", or "?") is a good idea, but not essential, and if you do it right then you can implement that once across your whole language (for applicatives/monads in general) and use it for eithers, futures, database transactions, audit logs, almost anything. https://philipnilsson.github.io/Badness10k/escaping-hell-wit... .

Checked (and unchecked) exceptions create an exponential number of control flow paths. Consider:

   try {
      throws_a();
      r = grab_resource();
      throws_b();
      r.throws_a();
   } catch (a) {
      r.release(); // oops; null pointer some times
   } catch (b) {
      try {
        r.release();
      } catch (a) {
        // nooo....
      } 
   } finally {
     if r != null {
        r.finalize() // use after release (sometimes)
        r.release() // ???
     } 
   }

There is plenty of academic literature showing that real programs are even worse than my contrived example, on average.

Ultimately, core language features that make things ergonomic enough for lazy developers to get it right will result in better software.

And ones that are so unergonomic that only industrious developers will get them right will result in worse software.

Modern languages allow these to be zero cost abstractions so there is little tradeoff.

> And I guess this is precisely why so many developers hate them; they don't like the extra work they have to do to catch all those edge conditions

I hate checked exceptions when they force me to handle an exception which I know is impossible given the arguments passed to the method. For example, some older Java APIs take an encoding name and force you to handle the checked UnsupportedEncodingException - even when the encoding name was something like “US-ASCII” or “UTF-8” which is required to exist by the Java standard, and if somehow they didn’t there is often no possible error recovery than just crashing. This has been fixed in newer versions by introducing new APIs which throw an unchecked exception instead, and also by introducing constant objects for the standard charsets

> Checked exceptions however are as safe

No. If I add a checked UserNotFound exception to a getUser db call, you can bet someone higher up the stack will do try catch Exception e, so now they're catching OutOfMemory and who knows what else.

I don't hate checked exceptions because they make me do extra work, I hate them because they inhibit the proper use of inheritance for OO design.

The problem with that is you lose all ability to understand or control what a given endpoint will return in any given situation

> I have no specific error handling for the given problem

then pass it on and decide what to do with it at the system boundary

in the db:

fun getUser(uuid: UUID) : Either<Error, User>

middle layers: pass around the either, you can map, flatmap etc on it to chain it with other computations there

then in the resource layer

return user .fold({ error -> when(error) { is DbError -> HttpResponse.InternalServerError() is UserNotFoundError -> HttpResponse.NotFound } }, { user -> HttpResponse.ok(user) })

Then, at every layer, each method explicitly says in the method signature what it returns. There’s no need to look around each and every line of every method in every layer, or in the framework, or some global exception handler, to figure out what will happen. Developers can tell from a glance at the resource method what the endpoint will return for each outcome, in context.

Things like being unable to communicate with the DB or not finding a user are not exceptional, they're entirely expectable when you're calling a db to look for a user and should be modeled accordingly.

Situations vary a lot. In general there's no guarantee that a far outer scope is going to know how to deal with errors from deep inside some nested calls except for some very general logic, like failing a whole operation.

In Rust you can just do "let value = result.unwrap()".

Especially because Kubernetes and the like work as if the application must die anyway. Pretty much like PHP CGI invocations always worked since 1998 or so.

They are unsafe because they invariably result in people either ignoring them or catching more than they should, or less than they should, and the compiler happily lets you do that, EVEN when you're using checked exceptions.

Definitely they have shortcomings in Java but throwing the concept out entirely is a bummer. It creates a whole shadow type system where all bets are off.

Yes! The problem with the Java implementation of checked exceptions is the inheritance hierarchy, which encourages catching the broadest possible error.

Which is now commonly wrapped into UncheckedIOException.

The number of exceptional errors one can reasonably handle is so small to be insignificant. Aborting the current operation (which could be just one task or the whole application) is the most common result. Abort and log. Unchecked exceptions make that easy. Checked exceptions make that long and tedious and add nothing.

What and where you can handle exceptions has nothing to do with where the exception is thrown. Handlers only exist at key points in the application at the start of operations where you can skip, abort, or retry.

its only an illusion of stability. so many things can go wrong outside of exceptions and all it does is add mandatory lines of code (probably rethrowing as a runtime exception) to every single consumer. It pollutes everything it touches.

I didn't know Java apps were so much more stable than C# ones.

Don't model those as Exceptions, because they are not exceptional. They are control flow.

I think this project shows how trivial it is to convert checked exception errors to compiler warnings.

https://github.com/rogerkeays/unchecked/blob/f22c8cde3557de0...

No need to change the type hierarchy. Just make it a compiler option.

As far as I know Zig errors can't carry any data along. It's nice having more details available about the failure.

Take for example if you call to an OS API and it returns an error that wasn't documented to be returned from that function. You can't return that code up the callstack using Zig's error mechanism. Instead there's functions such as unexpectedErrno and unexpectedError. Those call the appropriate method to get a string representation of the error and call std.debug.print to display it, then they just return error.Unexpected.

That means that the caller doesn't have any control over how the error is displayed. Meanwhile in Rust, you can add an UnexpectedError variant to your enum and let it carry an error code with it. The caller can then display that error however they want.

I don't hate Zig's error handling by any means, but personally I think Rust does it better. I'm happy to see that C++ seems to be going with the Rust way by adding a Result-like type std::expected.

It is true that C++ exceptions are not checked and are rarely part of the interface signature but C++ exceptions are not a tool for general error handling in the context you're comparing them against Java, Zig and Rust. Java uses exceptions for control flow while C++ doesn't. Zig and Rust don't have exceptions at all. What Zig and Rust have as error handling mechanisms C++ has them too. C++ exceptions are of a literal meaning - exceptional cases which you don't expect to happen and you usually don't know how to recover from. In this case propagating the exception up to the thread entry point and doing whatever in that case (logging, terminating, restarting, etc.) is vastly better than language forcing me to check for each possible exception all the way through the whole function callstack - it's useless.

I think the way Go does error handling is the best compromise.

Haskell and Rust can also throw exception/panic respectively in any call, ever.

Good point...

A lot of people, probably. But definitely not the entire community [0].

[0] https://www.yegor256.com/2015/07/28/checked-vs-unchecked-exc...

This is why you should have code reviews. Letting juniors submit code without reviewing it is a recipe for disaster, no matter which language you are programming in. And if it's a senior, well someone should have a word with him ..

At some point you want to swallow all checked exceptions at some point, because letting the application leak stack traces to the client is generally a bad idea.

The proper solution is effectful type systems that are polymorphic to effects, like exceptions.

The issue with checked exceptions in Java is that they are not supported in java lambda syntax and library functions.

I am using Eclipse. But will definitely keep this in mind, should I every switch to IntelliJ.

There's one big problem with this approach. You can't catch checked exception if the try-block does not throw it (according to compiler). That's compiler error.

So yes, you can throw IOException masking it to RuntimeException, however you can't catch it later without another gimmicks like catching Exception and checking if it's IOException (and even that check causes linter warnings in Idea, so now you need to suppress those warnings...).

Throwing and catching UncheckedIOException does not have this problem.

Disagree. Just because the ide wrote a bunch of boilerplate for me at some point doesn't mean I can know the boilerplate is unchanged without reading a bunch of getters and setters. The mental burden of tiny classes is so much nicer to read.

That's usually one time concern. Much better than having boilerplate lying around IMO.

Yes. It's fantastic see: https://debugagent.com/series/manifold

See my reply to jsight...