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

81–90 of 297 posts

Re: Unchecked Java: Say goodbye to checked exceptions

#81

Post by bedobi »

vips7L wrote: post #79
bedobi wrote: post #74

Earlier quoted context omitted.

whatever, the point is exception allows and encourages people to catch less and more than they should

Sometimes top level code needs to do this. It's not always wrong. It's not always black and white in programming.

> Sometimes top level code needs to do this

come on, it's not as if anyone disagrees with that, but that's extremely, extremely rare, overwhelmingly, callers are just dealing things like with UserNotFoundException, NullPointerException, what have you, and there's no reason why the compiler should happily let you catch Exception (or nothing) when it could just be giving you an honest object back

Re: Unchecked Java: Say goodbye to checked exceptions

#82

Post by kaba0 »

bedobi wrote: post #58
misja111 wrote: post #24

Earlier quoted context omitted.

Exception based error handling is unsafe when they are unchecked exceptions. Checked exceptions however are as safe as Either, Try, Monads, Applicatives or whatever. You are forced to declare them in your method signature, the caller is forced to either handle them or rethrow them + declare them as well. And I guess this is precisely why so many developers hate them; they don't like the extra work they have to do to…

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

As opposed to force unwrapping a Result type? Also, OutOfMemory is an error, exceptions won’t catch it.

Re: Unchecked Java: Say goodbye to checked exceptions

#83

Post by kaba0 »

titzer wrote: post #44
The_Colonel wrote: post #29

Earlier quoted context omitted.

> Safer because unlike exceptions, they force callers to handle all potential outcomes, but no more. Which is bad. In 99% of cases I have no specific error handling for the given problem. Just let the process crash or be handled by application server / framework. Representing these kinds of error conditions in the code which I have no interest in handling is just noise.

Situations vary a lot. In general there's no guarantee that a far outer scope is going to know how to deal with errors from deep inside some nested calls except for some very general logic, like failing a whole operation.

Even more commonly, there is no meaningful error handling to be done at a layer above the call.

Re: Unchecked Java: Say goodbye to checked exceptions

#84

Post by kaba0 »

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.

Go’s solution is like people couldn’t decide on if they should turn left, or turn right to avoid the cliff, so to make everyone happy they drove straight into it.

It is literally the compiler enforced shitty error handling from C’s errno that is not even a sum type.

Re: Unchecked Java: Say goodbye to checked exceptions

#85

Post by kaba0 »

_old_dude_ wrote: post #19
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

In Java, no method call is safe (Haskell/Rust safe), the langage will hapilly throws a null pointer exception or an out of memory error. But I don't think C#, Kotlin or Scala are less safe than Java even if they do not have the concept of checked exceptions.

Haskell and Rust can also throw exception/panic respectively in any call, ever.

Re: Unchecked Java: Say goodbye to checked exceptions

#86

Post by kaba0 »

ars wrote: post #69
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

Java just needs one small change to fix exceptions. Instead of the exception type being checked or unchecked, the throw should specify checked or unchecked. So for example the first time the exception happens it can throw a checked exception for the caller to deal with. If the caller doesn't deal with it it can simply throw its way all the way to the top without every single function needing to declare they handle it…

The proper solution is effectful type systems that are polymorphic to effects, like exceptions.

Re: Unchecked Java: Say goodbye to checked exceptions

#87

Post by esafak »

bedobi wrote: post #75
twelve40 wrote: post #73

Earlier quoted context omitted.

> you can bet someone higher up the stack will do try catch Exception e But that's laziness on the caller's part. If I offer a method but the caller decides to do reckless lazy crap with it, there are many different ways to get there in any language. I typically call those out (Exception e) at code reviews.

This is the most common reply I see whenever anyone proposes a safer, better way of coding, and it's not a good one

...because doing the right thing should be convenient, for its own good.

Re: Unchecked Java: Say goodbye to checked exceptions

#88

Post by jbverschoor »

bedobi wrote: post #58
misja111 wrote: post #24

Earlier quoted context omitted.

Exception based error handling is unsafe when they are unchecked exceptions. Checked exceptions however are as safe as Either, Try, Monads, Applicatives or whatever. You are forced to declare them in your method signature, the caller is forced to either handle them or rethrow them + declare them as well. And I guess this is precisely why so many developers hate them; they don't like the extra work they have to do to…

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

Re: Unchecked Java: Say goodbye to checked exceptions

#89

Post by wewtyflakes »

bedobi wrote: post #81
vips7L wrote: post #79

Earlier quoted context omitted.

Sometimes top level code needs to do this. It's not always wrong. It's not always black and white in programming.

> Sometimes top level code needs to do this come on, it's not as if anyone disagrees with that, but that's extremely, extremely rare, overwhelmingly, callers are just dealing things like with UserNotFoundException, NullPointerException, what have you, and there's no reason why the compiler should happily let you catch Exception (or nothing) when it could just be giving you an honest object back

It has not been extremely/overwhelmingly rare in my experience. Further still, within the context of Java, exceptions are objects.

Re: Unchecked Java: Say goodbye to checked exceptions

#90

Post by AnimalMuppet »

bedobi wrote: post #55
spion wrote: post #31

Earlier quoted context omitted.

Exceptions are not unsafe. That said, not modelling them in the type system is a mistake. But the model has to be useful - knowing what functions can or cannot throw is useful, knowing what they throw, less so. (They are safe because of try-finally / try-with-resources)

They are unsafe because they invariably result in people either ignoring them or catching more than they should, or less than they should, and the compiler happily lets you do that, EVEN when you're using checked exceptions.

How will the compiler let you catch less than you should when using checked exceptions?
Post reply on HN