Hacker News Reader

Comment by chii | Hacker News Reader

Removing checked exceptions - what a dangerous feature!

It's optional. It seems scary, but checked exceptions are a feature exclusive to the Java compiler -- the JVM does not enforce them. This is how JVM languages like Kotlin and others only use unchecked exceptions, and also how Manifold gets away with muting them as a compile-time feature.

It should not be optional :)

Checked exceptions is a stupid feature because it makes an implementation detail, the fact that a code raises an exception, part of the type of a method.

Scala, C# or Kotlin have no checked exception and it doesn't make them less safe.

No less safe until it the code is running in production on a Tuesday at 3AM and a library pukes up an exception it has never thrown before and your code doesn't handle it.

I prefer exceptions to be declared, just like types. Having exceptions declared gives me more information about the operation of the code I am calling and that is useful. To treat exception declarations just as annoyance seems like lazy punting.

Likely you don't care which exception is thrown, only that one is. In that case, it's overkill to add the exceptions to the type signature. You'd be far likely to be better off using IO<A> from Kotlin or IO[_] from Scala to model computations with exceptions as side-effects.

Besides, any non-trivial method that calls any set of libraries/frameworks would need to declare tens or hundreds of checked exceptions in your scenario. And that's just the catchable exceptions. What are you going to do about any (subclass of) Error?

that same 10s or 100s is true for error returns as well. what do you do with those?

convert it to internal types at the point you're exposed to them, then handle them in common ways. or re-throw as a general runtime exception if you don't have a way to handle it in your application. the difference with checked exceptions is that you have a correct, complete list of error scenarios that a library expects you to handle, and they provide a relatively easy way to defer handling.

there's no need for your `public static void main` to inherit all 100+ exception classes that your application is exposed to - that's just plain bad encapsulation.

---

granted, none of this touches on some of java's implementation issues, which essentially suffers from a lack of generics. e.g. you can't build an executor-framework without `raises Exception` or wrapping all errors in an internal wrapper, which loses compile-time safety. typed-exceptions-as-returns (i.e. typed result enums) keeps them within the normal type system, which does have some benefits for sure, but that ship has sailed. few languages are able to force exhaustive error handling at all, java's in a middle-ground with pros and cons.

The fact that a function can fail is not an implementation detail, it should be part of the signature of the method.

And if the method can suddenly fail in a new way, that signature should change so that callers of that method can adjust to the new failure case.

Checked exceptions force you to consider error cases, there's nothing stupid about them.

See the section on Lambdas:

http://manifold.systems/docs.html#checked-exception-suppress...

Reply on news.ycombinator.com