(I am primarily a C developer)

What is the problem with Checked Exceptions? Don't they just provide type checking? I would think that developers would want to know which function might or might not execute a non-local goto in middle of execution and handle that properly, since debugging that will be a mess.

Part of it is an ecosystem thing. It's a lot better now, but there were times when libraries would throw a variety of checked exceptions that usually couldn't be handled sensibly other than by being caught and logged by your top-level exception handler. This forced you to either

(a) pollute many methods on many layers of your class hierarchy with `throws X`, potentially also polluting your external API

(b) catch, wrap and re-throw the checked exception at every call site that could throw it

(c) Use Lombok's `@SneakyThrows` to convert a checked exception into an unchecked one. Which they advise against using on production code, and which I have definitely never used on production code.

There are specific situations where checked exceptions work well - where you want to say to specific code "I can fail in this specific way, and there is something sensible you can do about it". But those are fairly rare in my experience.

The only way to handle a checked exception is either by declaring `throws` in the function signature to propagate it, or by using annoying try-catch statement. Then, due to the verbosity of try-catch, some decided to misuse it with an empty catch block.

Personally, I think the problem isn't the checked exception itself, but rather the exception handling mechanism & popularity of unchecked exceptions. This led to some people misusing empty catch blocks or rethrowing with unchecked exception. Java 8+ functional interfaces / lambdas also don't play nicely with checked exceptions. There's no new keyword/feature/interaction between lambdas & checked exception, only old try-catch.

To this day (Java 24 and soon LTS 25), AFAIK there's 0 plan to improve Java checked exception. And there are a lot of quirks if you try to use checked exception with modern Java features. It's just all around painful to work with, and I prefer to use Result<T,E>-like with `sealed` sum-type nowadays.

It's quite weird the direction Java, C#, Javascript communities take on this. Lots of people just go with unchecked or using nullable reference. Which is fine for a throwaway program, but quite painful in a larger project. What do you mean a subtype / child class doesn't provide a supposedly "must be implemented" method `abstractMethod()` and instead throws an unchecked exception when you call it?

You can even see this in JDK standard library, take java.util.Collection.removeAll() for example (https://docs.oracle.com/javase/8/docs/api/java/util/Collecti...). A class implementing `Collection` interface might or might not throw unchecked exception, yet you can still do this and get runtime error:

  Collection<T> c = new ImmutableList<T>();
  c.removeAll();

In practice there are problems: Everything can throw IOException technically which you need to handle. There are non checked exception anyway, so there might be exception that are thrown anyway. It's a mess and there is a reason no other mainstream language uses them, even if Java people don't like that fact.

Imo, some standard libraries were massively overusing them. So, you needed to handle checked exceptions for stuff that you cant do much about or are highly improbable and genuinely should be runtime exceptions.

But other, even more common source of hate is that many people simply do not want to handle them. They prefer if they can kind of pretend that stuff does not exists and look like "10x fast developers". You are technically faster if you ignore all that stuff while someone else fixes your code later on in different ticket.