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

121–130 of 297 posts

Re: Unchecked Java: Say goodbye to checked exceptions

#121

Post by Supermancho »

rho4 wrote: post #22
nnnnico wrote: post #7

Allowing unchecked exceptions in languages without explicit error handling or the return of error values is a mistake IMO! Makes it impossible to call a function safely

I would argue the opposite: Junior and senior developers alike catch and swallow or log checked exceptions all over the place, making it impossible to know if your method call was successful or not.

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.

Re: Unchecked Java: Say goodbye to checked exceptions

#122

Post by andrekandre »

smallerfish wrote: post #103
WirelessGigabit wrote: post #72

Earlier quoted context omitted.

It feels like you're trying to use Exceptions as a way to steer your logic, otherwise why would you need to know why an operation failed to such detail? Your controller method cannot act differently on a DBConnectionerror or OutOfMemory error. Not to mention that exceptions cause developers to use them as control flow mechanisms. For example searching a user by id. If the database returns 0 records, is that reason to…

Or Kotlin's approach: fun getUser(userId: UUID): User? You cannot treat this result value as a `User` in code that calls this; though, once you null check it in your service layer, you can pass it on as `User` in the not-null branch. Null is nothing to be afraid of if the language forces you to declare nullability and deal with it.

this is a very common in obj-c too

on the other hand, depending on what your trying to do you might want to provide more context about what happened to the user/programmer

in swift you can change a throwing function to a nullable with `try?` so even if `getUser()` throws, you can keep it simple if thats what is appropriate

  guard let user = try? getUser(id: someUUID) else {
      return "user not found"
  }
as an aside, swift "throws" exceptions but these are just sugar for returning basically an Result and compose much better than traditional stack unwinding exceptions imo

Re: Unchecked Java: Say goodbye to checked exceptions

#123

Post by ziml77 »

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 one of the worst I've seen. It adds so much cognitive overhead to reading the code and makes it more annoying to write. Every function call that can fail is followed by 3 lines to check for and return the error. The actual logic quickly gets lost in there.

If it wasn't for the error handling, I would probably use Go for some of my projects. It compiles to a native, self-contained binary and still has the convenience of a garbage collector, and of course has plenty of libs available due to popularity.

Re: Unchecked Java: Say goodbye to checked exceptions

#124

Post by ziml77 »

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!

If you actually let it crash that's fine, but a lot of people just toss a catch (Exception ex) in there because they don't know what exceptions will happen and don't want errors that aren't actually a big deal to bring the system down. But the issue with catching everything, even if you log before continuing, is that the process may be in a bad state and you're just continuing with it like that. I got to see a couple database tables get absolutely mangled by a process that had an exception that was caught and logged. That was a pain to clean up since doing nothing more than restoring a backup would have lost the entire day's worth of business operations in that system.

Re: Unchecked Java: Say goodbye to checked exceptions

#125

Post by nradov »

breadwinner wrote: post #101

One of the biggest flaws in C#, in my experience, is lack of checked exceptions. As an example, I wrote some very good code, carefully tested it, made it work flawlessly, then suddenly it started crashing. What happened? Someone made a change in a function I was calling, and it started throwing a new exception. This would have caused a compile error in Java, not a crash. More on checked vs unchecked exceptions here:…

The trouble with checked exceptions is that they prevent you from easily extending classes or implementing interfaces that you don't control. Your new class might need to throw a checked exception not included in the method signature. So then you have to resort to hacks like wrapping the new checked exception inside a runtime exception.

Re: Unchecked Java: Say goodbye to checked exceptions

#126

Post by bottlepalm »

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.

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

Re: Unchecked Java: Say goodbye to checked exceptions

#127

Post by doliveira »

jabiko wrote: post #117
breadwinner wrote: post #101

One of the biggest flaws in C#, in my experience, is lack of checked exceptions. As an example, I wrote some very good code, carefully tested it, made it work flawlessly, then suddenly it started crashing. What happened? Someone made a change in a function I was calling, and it started throwing a new exception. This would have caused a compile error in Java, not a crash. More on checked vs unchecked exceptions here:…

Lets be honest. The more likely thing is that either the coworker would use an unchecked exception or that they would change the callsite to: try { theUpdatedFunction(); } catch (MyNewCheckedException e) { logger.warn("Whoopsie doopsie", e) throw new SomeUncheckedException("Something failed, idk", e) } Which really is a zero sum game. The code still breaks the same way, but the checked exception gets eventually wrapp…

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.

Re: Unchecked Java: Say goodbye to checked exceptions

#128

Post by sonicgear1 »

breadwinner wrote: post #101

One of the biggest flaws in C#, in my experience, is lack of checked exceptions. As an example, I wrote some very good code, carefully tested it, made it work flawlessly, then suddenly it started crashing. What happened? Someone made a change in a function I was calling, and it started throwing a new exception. This would have caused a compile error in Java, not a crash. More on checked vs unchecked exceptions here:…

You should catch any non specific exception in the last catch block, just in case. Thought that was the standard. Java gets very messy in mixing checked and unchecked exceptions, I've seen a lot of devs just ignore the unchecked ones.

Re: Unchecked Java: Say goodbye to checked exceptions

#129

Post by rcme »

titzer wrote: post #42
kaba0 wrote: post #28

Earlier quoted context omitted.

Checked exceptions are exactly analogous of Result/Either types. They are just built into the language with syntactic sugar, automatically unwrap by default (the most common operation), can be handled on as narrow or wide scope as needed (try-catch blocks), does the correct thing by default (bubbling up), and stores stack traces ! In my book, if anything, they are much much better! Unfortunately they don’t have a fla…

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

How would you define f in a different language such that f(g()) worked? You couldn’t do that in Go, for instance.

Re: Unchecked Java: Say goodbye to checked exceptions

#130

Post by rozap »

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

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.
Post reply on HN