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

231–240 of 297 posts

Re: Unchecked Java: Say goodbye to checked exceptions

#231

Post by jakewins »

com2kid wrote: post #223
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…

From a type theory perspective, an exception is another type of return value that a function can have, and not documenting those in the function signature is absurd. I have seen libraries that make network calls that do the following: * Throw an exception on certain types of network errors * Return an HTTP error code for other types of network errors * Return an object with error set to true and an error string for o…

I think the issue is with checked exceptions as a solution to how to declare this signature, or at least with how they are designed in Java: if you add a new exception to the signature, every downstream call site needs to change, recursively.

This means it is impossible to add new exceptions to library methods without breakage, and even in your own code it may mean hundreds of changes throughout your code to add a new exception type.

Rusts solution seems to have improved this conundrum, where you can describe how to map the new error into an existing hierarchy in a single or a few places instead of at every call site

Re: Unchecked Java: Say goodbye to checked exceptions

#232

Post by twelve40 »

mrkeen wrote: post #228
breadwinner wrote: post #173

Earlier quoted context omitted.

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?

> If so can you now understand why you would want to be alerted about a new exception getting thrown at compile-time as well? The library code can already throw anything. OutOfHeap, over/underflow, div0, stackoverflow, threadinterrupted. The caller already knows the function can throw, and documenting one more flavour of throw doesn't tell the caller anything.

> documenting one more flavour of throw doesn't tell the caller anything

but it does, in cases when there are errors that can or should be retried. Like a whitelist of documented cases where recovery and retry are possible, and of course all this infinite runtime stuff that can happen unexpectedly, for which there is no immediate solution.

Re: Unchecked Java: Say goodbye to checked exceptions

#233

Post by sobellian »

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.

If this were 100% true, everyone would want a language for formal verification (Idris, Coq, etc). Short of those lofty heights we can quibble over the varying strictness of Haskell vs Java vs C and so on.

Re: Unchecked Java: Say goodbye to checked exceptions

#234

Post by mrkeen »

misja111 wrote: post #45
renewiltord wrote: post #27

Earlier quoted context omitted.

Ultimately, core language features that make things ergonomic enough for lazy developers to get it right will result in better software. And ones that are so unergonomic that only industrious developers will get them right will result in worse software. Modern languages allow these to be zero cost abstractions so there is little tradeoff.

I have been coding in Scala/ Haskell for the last 10 years, before that 15 years in Java. What I'm seeing is that there are as many lazy developers in FP as there are in Java, maybe even more. And despite all the nice safeguards that FP provides, there are still plenty of ways for lazy devs to work around them. For instance the IO monad, which is used everywhere Scala/Cats. It can contain a result or an error. If you…

> It behaves just like a checked exception, the only difference is that methods don't need to declare any error or exception in their IO signature.

Then it behaves like an unchecked exception. Which is fine.

'Checking' is the act of modifying your source code to declare the error.

Re: Unchecked Java: Say goodbye to checked exceptions

#235

Post by Hackbraten »

briffid wrote: post #219

Checked exceptions turn out to be part of the API, meanwhile violating Liskov substitution principle and preventing some design patterns. This is because a superclass implementation might throw a checked exception, then its subclass not necessarily. However, if the caller refers the subclass instance via the superclass interface it must catch the exception, but if it refers via the subclass it must not catch, as that…

That’s not a Liskov violation. Changing the compile-time type of a local variable in the scope of the call site is not substituting the implementation of the referred-to object. Those are two different things.

As you correctly mentioned, if you leave the compile-time type of a variable unchanged, then assign a different object (one that belongs to a subclass that doesn’t throw the exception when you call its method) to that variable, and then call that same method, the compiler still forces you to catch. That’s the Liskov substitution.

Re: Unchecked Java: Say goodbye to checked exceptions

#236

Post by mrkeen »

the_gipsy wrote: post #63
nepthar wrote: post #46

Reading through the comments, I realize this may be a minority view - but I like coding for the happy path and letting exceptional states crash. I find languages like go a bit harder to parse quickly because I always have to "unwrap" the happy path from all of the mixed in error handling. I'm sure I'd get used to it eventually, but I like that unchecked exceptions in Java are now an option!

In practice there is a lot of paths that you don't want to "crash" on, but try the next thing etc.

Don't model those as Exceptions, because they are not exceptional. They are control flow.

Re: Unchecked Java: Say goodbye to checked exceptions

#237

Post by watwut »

lmm wrote: post #144
misja111 wrote: post #24

Earlier quoted context omitted.

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

Sorry but Either makes the code harder to read then exceptions. And harder to debug.

Re: Unchecked Java: Say goodbye to checked exceptions

#238

Post by jbverschoor »

bedobi wrote: post #91
jbverschoor wrote: post #88

Earlier quoted context omitted.

Then that person should get a Java 101 class. Or is this the current “staff software engineer” level of skills?

This is the most common reply I see whenever anyone proposes a safer, better way of coding, and it's not a good one. "Just get better" like oh ok except that in the real world people are gonna people and even the best programmers in the world make mistakes and do dumb, lazy shit. Our tools should be designed such that the safest, most correct way to do anything has the path of least the resistance. Not happily allow…

It’s not even lazy, your IDE will not do this for you by default.

It’s got nothing to do with getting better. It IS basic Java exception handling. Any proper course or tutorial will tell you to catch specific exceptions

Re: Unchecked Java: Say goodbye to checked exceptions

#239

Post by edejong »

sobellian wrote: post #233
breadwinner wrote: post #155

Earlier quoted context omitted.

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

If this were 100% true, everyone would want a language for formal verification (Idris, Coq, etc). Short of those lofty heights we can quibble over the varying strictness of Haskell vs Java vs C and so on.

A good programmer knows the limits of the type system. They lean on that knowledge to determine which tests to write.

Re: Unchecked Java: Say goodbye to checked exceptions

#240

Post by lmm »

watwut wrote: post #237
lmm wrote: post #144

Earlier quoted context omitted.

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

Sorry but Either makes the code harder to read then exceptions. And harder to debug.

Only if you're ignoring errors. If you actually catch and handle them the exception-based code becomes harder to read.
Post reply on HN