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

211–220 of 297 posts

Re: Unchecked Java: Say goodbye to checked exceptions

#211

Post by masklinn »

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.

You could actually, iirc if f takes as many parameters as g returns it works out.

In a better langage f would take a Result, and then it can manipulate that however it wants.

Obviously you can also plug in adapters if you need some other composition e.g. g().map(f), g().and_then(f), …

Re: Unchecked Java: Say goodbye to checked exceptions

#212

Post by kaba0 »

unscaled wrote: post #157
kaba0 wrote: post #28

Earlier quoted context omitted.

Checked exceptions are exactly analogous of Result/Either types. They are just built into the language with syntactic sugar, automatically unwrap by default (the most common operation), can be handled on as narrow or wide scope as needed (try-catch blocks), does the correct thing by default (bubbling up), and stores stack traces ! In my book, if anything, they are much much better! Unfortunately they don’t have a fla…

No, unfortunately they are not. The problem is not with checked exceptions themselves, but with the other type of exceptions in Java. In languages that rely on Result/Either for error handling, you've got two types of errors: Typed errors (Result/Either) and untyped panics. Typed errors are supposed to be handled, possibly based on their type, while panics can be recovered from ("catched") but these are serious, unex…

If all of those exceptions are custom made, then it makes sense to have a common subclass for them. It is not ideal, I agree, but it is hardly a showstopper.

Re: Unchecked Java: Say goodbye to checked exceptions

#213

Post by vbezhenar »

rogerkeays wrote: post #206
vbezhenar wrote: post #187

Checked exceptions are one of biggest mistakes Java ever made. That said, patching compiler is not something I would do. What I usually do is add unchecked exception class for every checked exception I had to "handle". So I have UncheckedIOException from standard library (handy!), UncheckedSQLException and so on and so on. Yes, it causes more code, but Java is not exactly known for brevity, so be it. At least that wa…

You can also rethrow checked exceptions as runtime exceptions by exploiting type erasure: public static RuntimeException unchecked(Exception e) { Exceptions. throw_checked(e); return null; } private static void throw_checked(Exception e) throws E { throw (E) e; } then you can do this: try { ... } catch (IOException e) { throw unchecked(e); } And the original exception is thrown without being wrapped. It's as though y…

There's one big problem with this approach. You can't catch checked exception if the try-block does not throw it (according to compiler). That's compiler error.

So yes, you can throw IOException masking it to RuntimeException, however you can't catch it later without another gimmicks like catching Exception and checking if it's IOException (and even that check causes linter warnings in Idea, so now you need to suppress those warnings...).

Throwing and catching UncheckedIOException does not have this problem.

Re: Unchecked Java: Say goodbye to checked exceptions

#214

Post by wvenable »

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…

> Safer because unlike exceptions, they force callers to handle all potential outcomes, but no more.

That's what wrong with them. Callers, in almost all cases, do not know what to do exceptional outcomes. So you force programmers into a situation where they're dealing with things they shouldn't be dealing with.

Re: Unchecked Java: Say goodbye to checked exceptions

#215

Post by bheadmaster »

breadwinner wrote: post #156
phillipcarter wrote: post #141

Earlier quoted context omitted.

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

Hejlsberg is a terrific compiler writer. Turbo Pascal was awesome! He is not a good language designer, however. The exception mess in C# is the proof. See my comment at the root of this thread.

I doubt you can evaluate man's skill through a single project. It's not nice to use ad hominem to advertise your own comment.

Re: Unchecked Java: Say goodbye to checked exceptions

#216

Post by [deleted] »

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…

[deleted]

Re: Unchecked Java: Say goodbye to checked exceptions

#217

Post by benjiweber »

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…

You can use checked exceptions equivalently to Result types in streams e.g. https://github.com/unruly/control/blob/master/src/test/java/...

Re: Unchecked Java: Say goodbye to checked exceptions

#218

Post by wvenable »

asddubs wrote: post #50
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!

I'm fine with doing this on purpose, but without a system like checked exceptions, you do it without even really realizing you're doing it. Checked exceptions point out the errors and then let you decide whether it's something you should handle or let it crash. It makes for more stable software.

The number of exceptional errors one can reasonably handle is so small to be insignificant. Aborting the current operation (which could be just one task or the whole application) is the most common result. Abort and log. Unchecked exceptions make that easy. Checked exceptions make that long and tedious and add nothing.

What and where you can handle exceptions has nothing to do with where the exception is thrown. Handlers only exist at key points in the application at the start of operations where you can skip, abort, or retry.

Re: Unchecked Java: Say goodbye to checked exceptions

#219

Post by briffid »

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 results in a compile error. So the point is that with checked exceptions you cannot replace an interface with any implementation, which should be possible in proper OO programming.

Re: Unchecked Java: Say goodbye to checked exceptions

#220

Post by hinkley »

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…

Let's be really honest

  try {
    theUpdatedFunction();
  } catch (MyNewCheckedException e) {
    logger.warn("Whoopsie doopsie", e);
    throw new SomeUncheckedException(e.message);
  }
There's a special place in Hell for these people, but at least they'll get to see all of their friends again.
Post reply on HN