Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Unchecked Java: Say goodbye to checked exceptions

github.com

Post reply on HN
Print view View original

201–210 of 297 posts

Re: Unchecked Java: Say goodbye to checked exceptions

#201

Post by WirelessGigabit »

wtetzner wrote: post #159
bedobi wrote: post #76

Earlier quoted context omitted.

WirelessGigabit gets it. That last fact is huge - functional error handling forces callers to handle (or pass on) exactly what can go wrong, no more, no less. (unlike exceptions)

That's not really true in practice. Often you just end up with a massive Error variant type that's used everywhere, even when the specific function you're calling could only return one of them.

You don't have to have Error variants if you don't care about their type.

You cannot catch a StackOverflowException or an OutOfMemoryException. All you do is log it & restart the app.

Once could split it into retryable errors and non-retryable ones. Like a DB disconnect, that can be retried.

BUT to be fair, that's not logic that belongs in the business.

Re: Unchecked Java: Say goodbye to checked exceptions

#202

Post by theanonymousone »

Putting aside the discussions about the necessity of checked exceptions (to which I feel unqualified to express my opinion), I believe the approach used by the OP article to remove them is not the best one:

- It requires modifying compiler arguments and putting some file in the local classpath! That's really not Java-ic. Is it?

- It is not transparent in the code. You cannot infer by looking at the source code that something has changed.

Since some time ago I use the NoException library[0] in my Java projects which achieves the same goal but without the above-mentioned issues. It can also be used to mimic Scala's Try construct.

[0] https://github.com/robertvazan/noexception

Re: Unchecked Java: Say goodbye to checked exceptions

#203

Post by slt2021 »

rogerkeays wrote: post #196
jitix wrote: post #136

Earlier quoted context omitted.

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…

I put Java's popularity down to good support for Corporate-Oriented Programming ;)

Coproporate-Oriented would be a better description

Re: Unchecked Java: Say goodbye to checked exceptions

#204

Post by masklinn »

erik_seaberg wrote: post #170
breadwinner wrote: post #155

Earlier quoted context omitted.

> 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.

stream.filter(p) requires wrapping checked exceptions in p, or altering the language so that they’re no longer checked. Same with Runnable.

You could also alter the langage woth for exceptions transparency (swift has something like that with “rethrows“).

I don’t think that’s close to sufficient to making checked exceptions work tho, let alone good.

Re: Unchecked Java: Say goodbye to checked exceptions

#205

Post by masklinn »

anon-3988 wrote: post #184
taeric wrote: post #113

Earlier quoted context omitted.

I mean, maybe? Fun degenerate cases to consider: Someone throws a Environment.Exit(0) into a random library you are using, instant pain. Someone throws an infinite loop into a library you are using, similar instant pain. 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. (I say this as someone that isn't really opposed…

> 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 or Option ) 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 comp…

> But surely this is a win?

Not when it creates more issues than it solves, which checked exceptions do.

Checked exceptions are an entire side channel to the type system which breaks any sort of composition or genericity.

Maybe this is solvable, but Java seriously poisoned that well because its implementation is so shit, and if you’re looking for this static safety, first the rest of a Java-style type system does not justify it (there’s so many low hanging fruits), and second a result-style things will already give you the same benefits in a form which is known to work.

Re: Unchecked Java: Say goodbye to checked exceptions

#206

Post by rogerkeays »

vbezhenar wrote: post #187

Checked exceptions are one of biggest mistakes Java ever made. That said, patching compiler is not something I would do. What I usually do is add unchecked exception class for every checked exception I had to "handle". So I have UncheckedIOException from standard library (handy!), UncheckedSQLException and so on and so on. Yes, it causes more code, but Java is not exactly known for brevity, so be it. At least that wa…

You can also rethrow checked exceptions as runtime exceptions by exploiting type erasure:

    public static RuntimeException unchecked(Exception e) {
        Exceptions.throw_checked(e); 
        return null; 
    }
    private static  void throw_checked(Exception e) throws E {
        throw (E) e;
    }
then you can do this:

    try { ...
    } catch (IOException e) {
        throw unchecked(e);
    }
And the original exception is thrown without being wrapped. It's as though you had `throws IOException` on your method signature.

This is from my original solution to the problem: https://github.com/rogerkeays/jamaica-core/blob/0cc98b114998...

Re: Unchecked Java: Say goodbye to checked exceptions

#207

Post by rixed »

colanderman wrote: post #197
breadwinner wrote: post #155

Earlier quoted context omitted.

> 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.

> You do not wrap checked exceptions in an unchecked one... unless you are a really bad Java programmer. I disagree -- this is the correct thing to do if you believe it is not possible for the checked exception to occur. (Catching it is wrong -- what would you do to correct something which you believe not to be possible? Forcing the caller to handle it is wrong -- if you don't know what to do with it, they sure won't…

> if you don't know what to do with it, they sure won't!

Actually no. For instance, the caller at some point up the stack may know if something is worth retrying.

Re: Unchecked Java: Say goodbye to checked exceptions

#208

Post by exabrial »

I love the idea of this project. Just needs some IDE and possibly some verifier support!

I do just want to correct a tiny piece of the readme:

> a common practise is to rethrow it as a RuntimeException. The problem with this, ... is that the root cause of exceptions get hidden,

This is most definitely not true. If you wrap / re-throw as a RuntimeException you will absolutely get your original stack trace.

Re: Unchecked Java: Say goodbye to checked exceptions

#209

Post by masklinn »

riku_iki wrote: post #146
smrtinsert wrote: post #139

Earlier quoted context omitted.

Agreed. I absolutely prefer checked exceptions since it forces devs and consequently business to develop requirements for possibilities. Lack of ambiguity helps me sleep at night. Potential runtime errors do not.

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

More generally the problem of checked exceptions in Java is that they are not supported by Java.

That was an issue right from the start, and it only got worse as the type system got richer.

Re: Unchecked Java: Say goodbye to checked exceptions

#210

Post by masklinn »

menaerus wrote: post #30
RGBCube wrote: post #14

Earlier quoted context omitted.

Exactly, C++ exceptions are horrible, you never know what throws what. Java made C++ exceptions better by making them explicit, so you always know what throws. Then Kotlin came and made everything a unusable mess (don't get me wrong, I love Kotlin, just hate that it doesn't have explicit exceptions). I honestly think the best error handling strategy is employed by Zig, then Rust. they're very explicit while not getti…

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 litera…

> 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

They’re literally the only way to report ctor errors.

> What Zig and Rust have as error handling mechanisms C++ has them too.

Only in the most reductive way that all langages are turing complete, in which case Java has them as well.

Post reply on HN