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

Re: Unchecked Java: Say goodbye to checked exceptions

#161

Post by nradov » Fri, Jul 14, 2023, 1:32 AM UTC

breadwinner wrote: post #158

nradov wrote: post #125

Earlier quoted context omitted.

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.

Not true. Exception hierarchies solve this problem.

Nope. Exception hierarchies don't even come close to solving that problem because the superclass or interface author usually didn't anticipate your need and define the method signature in a way that would be useful with exception hierarchies.

Re: Unchecked Java: Say goodbye to checked exceptions

#162

Post by hedora » Fri, Jul 14, 2023, 1:44 AM UTC

rcme wrote: post #129

titzer wrote: post #42

Earlier quoted context omitted.

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

In rust, you write "f(g()?)", and make sure that your function body returns a Result with an error type that g()'s error type can be converted to.

It works great. Also, note that f() doesn't care about the type of error returned by g(), and that it will be a compilation error if g()'s error type turns into something incompatible.

Sadly, there are proposals to add exceptions to rust, and it seems likely they will be accepted, breaking error handling semantics across the entire ecosystem (even in new code, since exceptions are too hard to use correctly).

Re: Unchecked Java: Say goodbye to checked exceptions

#163

Post by ben0x539 » Fri, Jul 14, 2023, 1:45 AM UTC

jcparkyn wrote: post #143

wvenable wrote: post #133

Earlier quoted context omitted.

Checked exceptions are just another return type with a weird syntax. It's not that Rust's result type is more versatile, it's just less syntax to accomplish what works out to be the same thing.

The difference is more than just syntax, at least in the case of Java and Rust. The core problem with checked exceptions in Java (as demonstrated in most of the examples from TFA) is that they don't compose properly with generic functions like map. Checked exceptions exist in parallel to the type system, and other parts of the language don't have the capacity to deal with them. On the other hand, a Result type makes…

Whoa, I've been having opinions about error handling and result types and checked exceptions for like years and I never considered that Java couldn't be "properly" polymorphic over checked exception types. Thanks for pointing that out.

Re: Unchecked Java: Say goodbye to checked exceptions

#164

Post by arcbyte » Fri, Jul 14, 2023, 1:46 AM UTC

WirelessGigabit wrote: post #72

The_Colonel wrote: post #59

Earlier quoted context omitted.

> The problem with that is you lose all ability to understand or control what a given endpoint will return in any given situation Why? In the simplest (but pretty common) case it's: - successful response - generic error message > then pass it on and decide what to do with it at the system boundary Yes, but if in 99% of cases I only pass it on, it's just visual noise. Noise you become blind to, and it loses meaning. >…

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…

Actually, I have some java code that handles OutOfMemoryError when I do image resizing. Of the image is so big that the decompressed versión can't fit in half a gig of memory (which happens) then I fall back to some crude subsampling to size it down. It's unnoticeably less pretty but works is how o handle OutOfMemoryErrors in a specific scenario.

Re: Unchecked Java: Say goodbye to checked exceptions

#165

Post by hedora » Fri, Jul 14, 2023, 1:49 AM UTC

misja111 wrote: post #24

bedobi wrote: post #20

Exception based error handling is so bad and unsafe that adopting functional error handling with Either, Try etc as implemented by functional addon libraries for many languages, while not yet common, in time it will become the new default even in OO languages. (just like it's been the default in functional languages for decades) Functional error handling types are much simpler, safer and more powerful. Simpler becaus…

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 (and unchecked) exceptions create an exponential number of control flow paths. Consider:

   try {
      throws_a();
      r = grab_resource();
      throws_b();
      r.throws_a();
   } catch (a) {
      r.release(); // oops; null pointer some times
   } catch (b) {
      try {
        r.release();
      } catch (a) {
        // nooo....
      } 
   } finally {
     if r != null {
        r.finalize() // use after release (sometimes)
        r.release() // ???
     } 
   }

There is plenty of academic literature showing that real programs are even worse than my contrived example, on average.

Re: Unchecked Java: Say goodbye to checked exceptions

#166

Post by insanitybit » Fri, Jul 14, 2023, 1:54 AM UTC

breadwinner wrote: post #155

jabiko wrote: post #117

Earlier quoted context omitted.

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…

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

> unless you are a really bad Java programmer.

Here's the thing. You've just described the vast majority of programmers - bad. They're really fucking bad. And language constructs that lead to bad programmers doing stupid things are, unfortunately making things worse for everyone.

Re: Unchecked Java: Say goodbye to checked exceptions

#167

Post by nradov » Fri, Jul 14, 2023, 1:57 AM UTC

misja111 wrote: post #24

bedobi wrote: post #20

Exception based error handling is so bad and unsafe that adopting functional error handling with Either, Try etc as implemented by functional addon libraries for many languages, while not yet common, in time it will become the new default even in OO languages. (just like it's been the default in functional languages for decades) Functional error handling types are much simpler, safer and more powerful. Simpler becaus…

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…

I don't hate checked exceptions because they make me do extra work, I hate them because they inhibit the proper use of inheritance for OO design.

Re: Unchecked Java: Say goodbye to checked exceptions

#168

Post by breadwinner » Fri, Jul 14, 2023, 1:58 AM UTC

nradov wrote: post #161

breadwinner wrote: post #158

Earlier quoted context omitted.

Not true. Exception hierarchies solve this problem.

Nope. Exception hierarchies don't even come close to solving that problem because the superclass or interface author usually didn't anticipate your need and define the method signature in a way that would be useful with exception hierarchies.

So you're inheriting a class not within your own application, but written outside of your application. Composition might work better in this case.

Re: Unchecked Java: Say goodbye to checked exceptions

#169

Post by rcme » Fri, Jul 14, 2023, 2:04 AM UTC

hedora wrote: post #162

rcme wrote: post #129

Earlier quoted context omitted.

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

In rust, you write "f(g()?)", and make sure that your function body returns a Result with an error type that g()'s error type can be converted to. It works great. Also, note that f() doesn't care about the type of error returned by g(), and that it will be a compilation error if g()'s error type turns into something incompatible. Sadly, there are proposals to add exceptions to rust, and it seems likely they will be a…

What's the rationale behind adding exceptions?

Re: Unchecked Java: Say goodbye to checked exceptions

#170

Post by erik_seaberg » Fri, Jul 14, 2023, 2:05 AM UTC

breadwinner wrote: post #155

jabiko wrote: post #117

Earlier quoted context omitted.

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…

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