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

131–140 of 297 posts

Re: Unchecked Java: Say goodbye to checked exceptions

#131

Post by wvenable »

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

> One of the biggest flaws in C#, in my experience, is lack of checked exceptions.

I couldn't disagree more. Checked exceptions in Java have ruined a generation of programmers.

The truth is, under checked exceptions, to satisfy the compiler the function that you called would declare that it throws a SomeModuleException and the programmer who wrote that function would put all his code in try/catch block that catches all errors and rethrows a SomeModuleException with the real exception passed as the cause.

Checked exceptions just don't work.

Re: Unchecked Java: Say goodbye to checked exceptions

#132

Post by bottlepalm »

code_runner wrote: post #100

To the credit of the die-hard Java community, you all really seem to love and support even the most horrific syntax and awful language features. You love the pain. The rest of us are here for you... I promise software can be fun. Checked exceptions are far and away the worst part of java and I'm glad that no other language I've personally encountered have them! On a more real note, I work at a shop with a fair amount…

Agreed, checked exceptions are awful. The idealists love them, the realest knows you can't write code up front handle every single exception case, and in most cases you aren't recovering from an exception anyways.

Especially the higher the level the code is the more potential lower layers that can fail. It's just not scalable to write code up front to deal with every single case. And most programmers don't care about failure, or working around it, just success.

On the other hand we do expect the unexpected and wrap failure prone code in try/catch so that we can log exceptions and keep the app moving. Figure out later if the ROI is there from enough failures to write special code to try to prevent and/or recover from a particular exception.

It's pretty much the same as it is in the checked exception world just with more code - in Java people handle the exception, log it and/or rethrow, so what's the point? Idealism and poor assumptions by the language designer. Anyone have any proof that a Java app is more reliable than a C# one?

Re: Unchecked Java: Say goodbye to checked exceptions

#133

Post by wvenable »

h4x0rr wrote: post #115
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

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.

Re: Unchecked Java: Say goodbye to checked exceptions

#134

Post by wvenable »

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

What does it mean to call a function safely?

I have a desktop application with a single exception handler wrapping it's event loop. The handler display the message to the user and returns the to loop. It's rock solid -- nothing can crash it. The user can try to save their file to some network share that just disappeared and when that fails just save again somewhere else.

But there is no such thing a safe function to call. Whether you handle errors by meticulously passing them around everywhere or not makes little difference.

Re: Unchecked Java: Say goodbye to checked exceptions

#135

Post by [deleted] »

skissane wrote: post #112
breadwinner wrote: post #109

Earlier quoted context omitted.

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

[deleted]

Re: Unchecked Java: Say goodbye to checked exceptions

#136

Post by jitix »

wvenable wrote: post #131
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:…

> One of the biggest flaws in C#, in my experience, is lack of checked exceptions. I couldn't disagree more. Checked exceptions in Java have ruined a generation of programmers. The truth is, under checked exceptions, to satisfy the compiler the function that you called would declare that it throws a SomeModuleException and the programmer who wrote that function would put all his code in try/catch block that catches a…

You’re both right and wrong. Checked exceptions slow down development, make code ugly and in my theoretical opinion are an anti-pattern that should never be used.

However in small to mid sized enterprise software companies with average developer talent it’s important to keep boundaries (and blame) clear.

In the scenario in question, the CTO will blame OP and make them work the weekend to diagnose/fix it, so wrapping the other exception and throwing their own SomeModuleException will cover their ass.

Java is popular for all the wrong reasons. Believe it or not there are hundreds of such companies in the US alone heavily using Java in this manner and then there is the whole offshore development segment.

Re: Unchecked Java: Say goodbye to checked exceptions

#137

Post by w10-1 »

The friction between the benefits of detecting errors statically, handling them quickly, and the diversity of needs for error handling cannot be avoided with any fixed policy like "unchecked only".

This tool does remind us that checked exceptions in Java are a compile-time phenomenon only, so (non-compliant) compilers can be made to ignore them. Neat, but... helpful? It would certainly lock you into using the tool.

Instead, we need configurable policies for error handling, where the same code can be statically analyzed much more deeply (e.g., to include unchecked exceptions) or run more leniently (e.g., when exceptions are used only for flow control). Some of this might pertain to local declarations, and some might be policies of various scopes (per VM, per-package, or per call-chain), and would probably fold in assertions and fibers/virtual threads and some OS-sensitive behaviors. The goal would be to write the code once (with full disclosure, i.e., only check-able exceptions and assertions), but to reuse the same code under different policies.

Whether anyone wants to do the work of folding this into the VM as security privileges were is another question...

Re: Unchecked Java: Say goodbye to checked exceptions

#138

Post by titzer »

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.

There's at least one language, Koka (https://koka-lang.github.io/koka/doc/book.html) that has effects in its type system. There are probably others. If you don't have effects, you could use union types.

Re: Unchecked Java: Say goodbye to checked exceptions

#139

Post by smrtinsert »

w10-1 wrote: post #137

The friction between the benefits of detecting errors statically, handling them quickly, and the diversity of needs for error handling cannot be avoided with any fixed policy like "unchecked only". This tool does remind us that checked exceptions in Java are a compile-time phenomenon only, so (non-compliant) compilers can be made to ignore them. Neat, but... helpful? It would certainly lock you into using the tool. I…

Agreed. I absolutely prefer checked exceptions since it forces devs and consequently business to develop requirements for possibilities. Lack of ambiguity helps me sleep at night. Potential runtime errors do not.

Re: Unchecked Java: Say goodbye to checked exceptions

#140

Post by joiqj »

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

One of the reasons I hate exceptions overall. Someone may add new ones, they break the control flow, they bubble up all over the place, etc etc. They are basically indomitable.
Post reply on HN