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

Re: Unchecked Java: Say goodbye to checked exceptions

#171

Post by pestatije » Fri, Jul 14, 2023, 2:06 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.

i do...if i ever get an IOException all i have to do is end the app, no need to deal with it in any way different than an unchecked exception

https://phauer.com/2015/checked-exceptions-are-evil/

Re: Unchecked Java: Say goodbye to checked exceptions

#172

Post by nradov » Fri, Jul 14, 2023, 2:09 AM UTC

breadwinner wrote: post #168

nradov wrote: post #161

Earlier quoted context omitted.

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.

Nope. Composition doesn't help when you have to implement an existing interface in order to make some API work.

Re: Unchecked Java: Say goodbye to checked exceptions

#173

Post by breadwinner » Fri, Jul 14, 2023, 2:25 AM UTC

taeric wrote: post #113

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…

If someone added an extra parameter to a function you're calling, when would you want to be alerted about it? At compile time? Or when you rerun all the tests?

Hopefully, your answer is compile time. If so can you now understand why you would want to be alerted about a new exception getting thrown at compile-time as well?

Re: Unchecked Java: Say goodbye to checked exceptions

#174

Post by int_19h » Fri, Jul 14, 2023, 2:28 AM UTC

sonicgear1 wrote: post #128

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.

And do what with it? If you don't know what it really is, the best thing is to let things fail fast and the standard logging to kick in and record all the details of the crash.

Re: Unchecked Java: Say goodbye to checked exceptions

#175

Post by breadwinner » Fri, Jul 14, 2023, 2:32 AM UTC

sonicgear1 wrote: post #128

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.

So you mean, catch the root Exception class. Pretty much everyone agrees that's a bad idea, C# and Java both advice against that. But in the case of C# you have to do it, to avoid crashing all the time, because there's no reliable way to determine what exceptions can be expected. In Java the compiler will tell you what exceptions can be expected, but in C# you have to rely on documentation which is not reliable.

Re: Unchecked Java: Say goodbye to checked exceptions

#176

Post by int_19h » Fri, Jul 14, 2023, 2:34 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…

That's a specific choice that Java designers made, though, not something inherent to checked exceptions in principle. During Project Lambda, one of the proposals - Neal Gafter's - actually had a full-fledged generic exception specification facility that allowed you to define HOFs along the lines of "I throw everything X does, and also Y". They killed it because it was "too complicated".

Re: Unchecked Java: Say goodbye to checked exceptions

#177

Post by yardstick » Fri, Jul 14, 2023, 2:36 AM UTC

int_19h wrote: post #174

sonicgear1 wrote: post #128

Earlier quoted context omitted.

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.

And do what with it? If you don't know what it really is, the best thing is to let things fail fast and the standard logging to kick in and record all the details of the crash.

Depends on what you are doing.

If I’m processing a monthly report for millions of customers, I don’t want to abort processing after running into one problem customer. I want to continue to process the rest of them, and log the problem customers exception for troubleshooting and analysis offline.

Re: Unchecked Java: Say goodbye to checked exceptions

#178

Post by int_19h » Fri, Jul 14, 2023, 2:38 AM UTC

nradov wrote: post #172

breadwinner wrote: post #168

Earlier quoted context omitted.

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

Nope. Composition doesn't help when you have to implement an existing interface in order to make some API work.

If you're implementing an existing interface for that reason, it's because something else is going to be calling you. In which case throwing an exception that they don't expect is probably a bad idea, and relying on it just flowing through their code back to you is basically relying on implementation details in many cases.

Re: Unchecked Java: Say goodbye to checked exceptions

#179

Post by int_19h » Fri, Jul 14, 2023, 2:41 AM UTC

the_gipsy wrote: post #60

kaba0 wrote: post #49

Earlier quoted context omitted.

Read my last paragraph.

So they are better... in a theoretical implementation.

A prototype of the Java compiler with composable checked exceptions existed at one point, so we know it's definitely doable.

Re: Unchecked Java: Say goodbye to checked exceptions

#180

Post by yardstick » Fri, Jul 14, 2023, 2:41 AM UTC

breadwinner wrote: post #175

sonicgear1 wrote: post #128

Earlier quoted context omitted.

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.

So you mean, catch the root Exception class. Pretty much everyone agrees that's a bad idea, C# and Java both advice against that. But in the case of C# you have to do it, to avoid crashing all the time, because there's no reliable way to determine what exceptions can be expected. In Java the compiler will tell you what exceptions can be expected, but in C# you have to rely on documentation which is not reliable.

Not just Exception. Throwable.

I’ve seen too much code were some random problem in an Error - OutOfMemoryError for example when processing too much data (Eg call data records, payment records, analytic records, whatever). If it’s a batch processing job, you don’t want this problem for this specific entity causing the rest of your reports not to be sent.

I’ve also seen stupid things like RPC libraries silently swallow Errors and not report them properly to the caller, so we end up wrapping all RPC server endpoint methods in a try-catch-Throwable just so we can see the problem and log it.