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

Re: Unchecked Java: Say goodbye to checked exceptions

#111

Post by _old_dude_ » Thu, Jul 13, 2023, 10:19 PM UTC

kaba0 wrote: post #85

_old_dude_ wrote: post #19

Earlier quoted context omitted.

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.

Technically true, but Haskell forces you to use the IO monad and you can not really recover from a panic in Rust, the thread is dead.

Re: Unchecked Java: Say goodbye to checked exceptions

#112

Post by skissane » Thu, Jul 13, 2023, 10:23 PM UTC

breadwinner wrote: post #109

skissane wrote: post #106

Earlier quoted context omitted.

> 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. Not necessarily. If it started throwing a new RuntimeException, it wouldn’t have. There are also sneaky ways to throw checked exceptions without declaring them, for example using Lombok’s @SneakyThrows annotation

Certainly you can intentionally break it, but then that's on you.

A person can also accidentally break it - by adding some new code which contains a bug which causes an unchecked exception or error to be thrown (e.g. NullPointerException, ArrayIndexOutOfBoundsException, StackOverflowError, etc).

Checked exceptions do nothing to protect against those kinds of mistakes, which in my personal experience are vastly more common than whatever mistakes for which they may provide some protection

Re: Unchecked Java: Say goodbye to checked exceptions

#113

Post by taeric » Thu, Jul 13, 2023, 10:26 PM UTC

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

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 to checked exceptions.)

Re: Unchecked Java: Say goodbye to checked exceptions

#114

Post by kaba0 » Thu, Jul 13, 2023, 10:31 PM UTC

_old_dude_ wrote: post #111

kaba0 wrote: post #85

Earlier quoted context omitted.

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

Technically true, but Haskell forces you to use the IO monad and you can not really recover from a panic in Rust, the thread is dead.

  head []

No monad, nothing, just an exception.

Re: Unchecked Java: Say goodbye to checked exceptions

#115

Post by h4x0rr » Thu, Jul 13, 2023, 10:32 PM UTC

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

Checked exceptions just always felt annoying to work with. Imo Rust's Result type is more versatile

Re: Unchecked Java: Say goodbye to checked exceptions

#116

Post by kaba0 » Thu, Jul 13, 2023, 10:32 PM UTC

DarkNova6 wrote: post #108

kaba0 wrote: post #82

Earlier quoted context omitted.

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

What about DivisionByZero, NumberFormatexception, ArrayStoreException? There are countless examples of rare but legit non-obscure use-cases. And even if your code is fine, you can't expect the same for the libraries you are using. And some exceptions make frequent non-happy paths more visible. Most of all IOException, because IO can _always_ fail for all the wrong reasons (because the failing of this exception is out…

Was that comment meant for me?

Re: Unchecked Java: Say goodbye to checked exceptions

#117

Post by jabiko » Thu, Jul 13, 2023, 10:32 PM UTC

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 wrapped in an unchecked one. We still would have the situation that someone changed the behavior of the function in a way that is incompatible with your usage.

That bug should have been caught by tests, code reviews and good communication.

Re: Unchecked Java: Say goodbye to checked exceptions

#118

Post by oh_sigh » Thu, Jul 13, 2023, 10:33 PM UTC

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

Your code might have been very good, but it wasn't future proof. It sounds like your code would have been fine if you locked down the libraries you were calling to a fixed version or something.

Re: Unchecked Java: Say goodbye to checked exceptions

#119

Post by __jem » Thu, Jul 13, 2023, 10:38 PM UTC

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

On the other hand, in lots of application code, there's often not much to do other than crash or abort the request, and this can often be safer than trying to proceed along code paths that are almost always under-tested. We've all seen Java code where a junior has decided to swallow an error without much thought. This obviously isn't true for every use case, but failing fast is often a pretty good policy.

Re: Unchecked Java: Say goodbye to checked exceptions

#120

Post by __jem » Thu, Jul 13, 2023, 10:43 PM UTC

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…

Or, worse, you're reviewing a large diff, see the logger statement but don't notice that the junior whose code you're reviewing forgot to rethrow. Now you've accidentally entered uncharted territory where way more scarier things can happen to your application than just crashing. Of course this shouldn't happen, but it does.