Unchecked Java: Say goodbye to checked exceptions • Hacker News Board

Re: Unchecked Java: Say goodbye to checked exceptions

#91

Post by bedobi » Thu, Jul 13, 2023, 9:14 PM UTC

jbverschoor wrote: post #88

bedobi wrote: post #58

Earlier quoted context omitted.

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

Then that person should get a Java 101 class. Or is this the current “staff software engineer” level of skills?

This is the most common reply I see whenever anyone proposes a safer, better way of coding, and it's not a good one. "Just get better" like oh ok except that in the real world people are gonna people and even the best programmers in the world make mistakes and do dumb, lazy shit. Our tools should be designed such that the safest, most correct way to do anything has the path of least the resistance. Not happily allow you to ignore exceptions, or catch less or more exceptions than required. Functional error handling corrects this, exceptions do not. Anyway, it's clear we're not going to agree, and you win, since so far the industry is still stubbornly clinging to exceptions, despite them being a failed feature in every language they're in.

Re: Unchecked Java: Say goodbye to checked exceptions

#92

Post by AnimalMuppet » Thu, Jul 13, 2023, 9:16 PM UTC

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…

In what way are Java exceptions part of flow control and C++ exceptions aren't?

Re: Unchecked Java: Say goodbye to checked exceptions

#93

Post by macpete42 » Thu, Jul 13, 2023, 9:23 PM UTC

catch them at the source and return sealed classes (used like sum types) instead

Re: Unchecked Java: Say goodbye to checked exceptions

#94

Post by code_runner » Thu, Jul 13, 2023, 9:28 PM UTC

asddubs wrote: post #50

nepthar wrote: post #46

Reading through the comments, I realize this may be a minority view - but I like coding for the happy path and letting exceptional states crash. I find languages like go a bit harder to parse quickly because I always have to "unwrap" the happy path from all of the mixed in error handling. I'm sure I'd get used to it eventually, but I like that unchecked exceptions in Java are now an option!

I'm fine with doing this on purpose, but without a system like checked exceptions, you do it without even really realizing you're doing it. Checked exceptions point out the errors and then let you decide whether it's something you should handle or let it crash. It makes for more stable software.

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.

Re: Unchecked Java: Say goodbye to checked exceptions

#95

Post by code_runner » Thu, Jul 13, 2023, 9:29 PM UTC

edpichler wrote: post #47

This dependency removes one of the best features of Java, which make others think about what happens if things go wrong.

only the things that someone acknowledges may go wrong

Re: Unchecked Java: Say goodbye to checked exceptions

#96

Post by code_runner » Thu, Jul 13, 2023, 9:29 PM UTC

watwut wrote: post #18

Nothing better then having to guess whether the method may throw an exception or not.

nothing better than someone assuming a method can only throw a specific type of exception or won't throw at all.

Re: Unchecked Java: Say goodbye to checked exceptions

#97

Post by pharmakom » Thu, Jul 13, 2023, 9:33 PM UTC

_old_dude_ wrote: post #34

asddubs wrote: post #3

I actually quite like checked exceptions, and miss them in other languages. My biggest gripe with exceptions is that a few calls deep, you can no longer tell whether calling something might throw or not, and what type of exception it might potentially throw.

Checked exceptions are a leaky concept in Java. The Java type system has no union types so you can not have a generics method that abstract more than one exception. That's why Stream::map can not capture the checked exceptions properly.

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

Re: Unchecked Java: Say goodbye to checked exceptions

#98

Post by nabogh » Thu, Jul 13, 2023, 9:33 PM UTC

jameslars wrote: post #12

flerchin wrote: post #6

Neat. Reminds me of lombok in that it really only affects compile-time and makes for cleaner code in a way that many (but not all) developers would want.

Ugh Lombok! Literally everything it does is replaced by any competent IDE with auto-generated methods, with the added benefit of not requiring special build handling steps because the library can't play by the normal annotation processing rules. There was maybe a time Lombok made sense. It does not anymore. Death to Lombok.

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.

Re: Unchecked Java: Say goodbye to checked exceptions

#99

Post by vips7L » Thu, Jul 13, 2023, 9:34 PM UTC

SomeRndName11 wrote: post #17

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…

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

It’s honestly the worst compromise. You can trivially ignore any error in Go and they don’t contain contextual information about the call stack.

Re: Unchecked Java: Say goodbye to checked exceptions

#100

Post by code_runner » Thu, Jul 13, 2023, 9:38 PM UTC

To the credit of the die-hard Java community, you all really seem to love and support even the most horrific syntax and awful language features. You love the pain. The rest of us are here for you... I promise software can be fun.

Checked exceptions are far and away the worst part of java and I'm glad that no other language I've personally encountered have them!

On a more real note, I work at a shop with a fair amount of java now and checked exceptions are definitely my biggest complaint. I hope we adopt this, I'm sure we won't, but I'm glad to see a little movement on what I feel is the crusty status quo in the java world.