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

31–40 of 297 posts

Re: Unchecked Java: Say goodbye to checked exceptions

#31

Post by spion »

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…

Exceptions are not unsafe.

That said, not modelling them in the type system is a mistake. But the model has to be useful - knowing what functions can or cannot throw is useful, knowing what they throw, less so.

(They are safe because of try-finally / try-with-resources)

Re: Unchecked Java: Say goodbye to checked exceptions

#32

Post by rogerkeays »

_old_dude_ wrote: post #19
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

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.

Good point...

Re: Unchecked Java: Say goodbye to checked exceptions

#34

Post by _old_dude_ »

asddubs wrote: post #3

I actually quite like checked exceptions, and miss them in other languages. My biggest gripe with exceptions is that a few calls deep, you can no longer tell whether calling something might throw or not, and what type of exception it might potentially throw.

Checked exceptions are a leaky concept in Java. The Java type system has no union types so you can not have a generics method that abstract more than one exception.

That's why Stream::map can not capture the checked exceptions properly.

Re: Unchecked Java: Say goodbye to checked exceptions

#35

Post by ziml77 »

RGBCube wrote: post #14
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

Exactly, C++ exceptions are horrible, you never know what throws what. Java made C++ exceptions better by making them explicit, so you always know what throws. Then Kotlin came and made everything a unusable mess (don't get me wrong, I love Kotlin, just hate that it doesn't have explicit exceptions). I honestly think the best error handling strategy is employed by Zig, then Rust. they're very explicit while not getti…

As far as I know Zig errors can't carry any data along. It's nice having more details available about the failure.

Take for example if you call to an OS API and it returns an error that wasn't documented to be returned from that function. You can't return that code up the callstack using Zig's error mechanism. Instead there's functions such as unexpectedErrno and unexpectedError. Those call the appropriate method to get a string representation of the error and call std.debug.print to display it, then they just return error.Unexpected.

That means that the caller doesn't have any control over how the error is displayed. Meanwhile in Rust, you can add an UnexpectedError variant to your enum and let it carry an error code with it. The caller can then display that error however they want.

I don't hate Zig's error handling by any means, but personally I think Rust does it better. I'm happy to see that C++ seems to be going with the Rust way by adding a Result-like type std::expected.

Re: Unchecked Java: Say goodbye to checked exceptions

#36

Post by tasubotadas »

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

The entire community disagrees with you[1]

>Makes it impossible to call a function safely ?? catch(Exception e) anyone?

[1] https://literatejava.com/exceptions/checked-exceptions-javas...

Re: Unchecked Java: Say goodbye to checked exceptions

#39

Post by misja111 »

rho4 wrote: post #22
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

I would argue the opposite: Junior and senior developers alike catch and swallow or log checked exceptions all over the place, making it impossible to know if your method call was successful or not.

This is why you should have code reviews. Letting juniors submit code without reviewing it is a recipe for disaster, no matter which language you are programming in. And if it's a senior, well someone should have a word with him ..

Re: Unchecked Java: Say goodbye to checked exceptions

#40

Post by never_inline »

jameslars wrote: post #12
flerchin wrote: post #6

Neat. Reminds me of lombok in that it really only affects compile-time and makes for cleaner code in a way that many (but not all) developers would want.

Ugh Lombok! Literally everything it does is replaced by any competent IDE with auto-generated methods, with the added benefit of not requiring special build handling steps because the library can't play by the normal annotation processing rules. There was maybe a time Lombok made sense. It does not anymore. Death to Lombok.

That's usually one time concern. Much better than having boilerplate lying around IMO.
Post reply on HN