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

141–150 of 297 posts

Re: Unchecked Java: Say goodbye to checked exceptions

#141

Post by phillipcarter »

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…

Yep. This is similar to a viewpoint by Anders Hejlsberg and many on the C# team at the time: https://www.artima.com/articles/the-trouble-with-checked-exc...

> You see programmers picking up new APIs that have all these throws clauses, and then you see how convoluted their code gets, and you realize the checked exceptions aren't helping them any.

And he goes on to elaborate on how this gets more complicated when versioning is introduced into the mix.

Re: Unchecked Java: Say goodbye to checked exceptions

#142

Post by coldtea »

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…

>The code still breaks the same way

That's not a valid argument. This is an explicit decision, so they reap what they sowed.

One could just as well make the same argument for Optionals, that you can just do:

  let val = foo.unwrap();

Re: Unchecked Java: Say goodbye to checked exceptions

#143

Post by jcparkyn »

wvenable wrote: post #133
h4x0rr wrote: post #115

Earlier quoted context omitted.

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.

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 errors part of the type system, and all other code can work with them "by default".

Re: Unchecked Java: Say goodbye to checked exceptions

#144

Post by lmm »

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…

> And I guess this is precisely why so many developers hate them; they don't like the extra work they have to do to catch all those edge conditions. This is why we see so many empty catch blocks or upcasting to Exception or even Throwable; it is laziness.

Good developers should be lazy. Checked exceptions require you to do a bunch of cumbersome ceremony that makes your code unreadable, for what should be (and is, with Either or equivalent) at most a couple of symbols; no wonder developers hate that.

> I would also argue that checked exceptions are no more complex than Eithers, Try or Applicatives.

You'd be wrong. Checked exceptions as implemented in Java require two keywords of their own (throw and catch), a special change to method signatures (throws), a unique new kind of expression for multi-catch (|), a unique new kind of type for things caught in multi-catches, and special support in every other new language feature (e.g. Futures have a whole bunch of extra code to deal with exceptions). Eithers can literally be a regular class that you could write yourself using ordinary language features. A small piece of syntax sugar (something like "do notation", "for/yield comprehensions", or "?") is a good idea, but not essential, and if you do it right then you can implement that once across your whole language (for applicatives/monads in general) and use it for eithers, futures, database transactions, audit logs, almost anything. https://philipnilsson.github.io/Badness10k/escaping-hell-wit... .

Re: Unchecked Java: Say goodbye to checked exceptions

#145

Post by clhodapp »

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.

Simple! You just make f take in g's result type.

Re: Unchecked Java: Say goodbye to checked exceptions

#146

Post by riku_iki »

smrtinsert wrote: post #139
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.

The issue with checked exceptions in Java is that they are not supported in java lambda syntax and library functions.

Re: Unchecked Java: Say goodbye to checked exceptions

#147

Post by clhodapp »

kaba0 wrote: post #82
bedobi wrote: post #58

Earlier quoted context omitted.

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

You can choose to unwrap the result type wherever you want, as opposed to it automatically unwrapping in place at the call site and having a weird propensity to encourage a "special" return from there.

Re: Unchecked Java: Say goodbye to checked exceptions

#148

Post by vips7L »

AnimalMuppet wrote: post #92
menaerus wrote: post #30

Earlier quoted context omitted.

It is true that C++ exceptions are not checked and are rarely part of the interface signature but C++ exceptions are not a tool for general error handling in the context you're comparing them against Java, Zig and Rust. Java uses exceptions for control flow while C++ doesn't. Zig and Rust don't have exceptions at all. What Zig and Rust have as error handling mechanisms C++ has them too. C++ exceptions are of a litera…

In what way are Java exceptions part of flow control and C++ exceptions aren't?

Honestly who cares if they are? Error handling is control flow.

Re: Unchecked Java: Say goodbye to checked exceptions

#149

Post by wvenable »

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…

I agree. Checked exceptions are just a worse version of Result types. I did not intend to make them sound better than they are.

Unchecked exceptions, however, are a different beast entirely. They're not just checked exceptions without the checking; they fundamentally change how you code and how you think about error handling.

Re: Unchecked Java: Say goodbye to checked exceptions

#150

Post by adamwk »

jitix wrote: post #136
wvenable wrote: post #131

Earlier quoted context omitted.

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

But even with unchecked exceptions, the exception value or description will still show up in the logs. I don’t understand how checked exceptions save you from a tyrannical CTO
Post reply on HN