Unchecked Java: Say goodbye to checked exceptions • Hacker News Board

Re: Unchecked Java: Say goodbye to checked exceptions

#181

Post by int_19h » Fri, Jul 14, 2023, 2:45 AM UTC

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…

It's the ergonomics of it. For a checked exception facility to not be maddening, it needs to have good facilities to propagate and wrap exceptions easily and with minimal scaffolding. But for some reason no mainstream language with traditional exception handling did that.

In a similar vein, it's ironic how often you hear "composition is better than inheritance" in OO design context, and yet how few OO languages have facilities to automate delegation.

Re: Unchecked Java: Say goodbye to checked exceptions

#182

Post by emi2k01 » Fri, Jul 14, 2023, 2:47 AM UTC

rcme wrote: post #169

hedora wrote: post #162

Earlier quoted context omitted.

In rust, you write "f(g()?)", and make sure that your function body returns a Result with an error type that g()'s error type can be converted to. It works great. Also, note that f() doesn't care about the type of error returned by g(), and that it will be a compilation error if g()'s error type turns into something incompatible. Sadly, there are proposals to add exceptions to rust, and it seems likely they will be a…

What's the rationale behind adding exceptions?

I'm not sure what they mean by adding exceptions.

AFAIK, the only proposal related to exceptions is adding a `try` block that would scope the `?` operator to that block instead of the current function.

Re: Unchecked Java: Say goodbye to checked exceptions

#183

Post by earthboundkid » Fri, Jul 14, 2023, 2:49 AM UTC

Conceptually there’s not much difference between checked exceptions and multiple returns or returning a tuple with an error etc. The problem with Java is that the checked exceptions are too fine grained, so the signatures are brittle and non-composable. Everything should just throw an Exception and then use dynamic typing to figure the rest out, and then you wouldn’t have the problem that your toList method can’t compose with something that throws an unknown Exception subclass.

Re: Unchecked Java: Say goodbye to checked exceptions

#184

Post by anon-3988 » Fri, Jul 14, 2023, 2:50 AM UTC

taeric wrote: post #113

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

I mean, maybe? Fun degenerate cases to consider: Someone throws a Environment.Exit(0) into a random library you are using, instant pain. Someone throws an infinite loop into a library you are using, similar instant pain. There is no magic language trick that can prevent you from having to rerun all tests for your software if you update a dependency. Pretty much period. (I say this as someone that isn't really opposed…

> There is no magic language trick that can prevent you from having to rerun all tests for your software if you update a dependency. Pretty much period.

Of course, but having a checked exception (even better, having the errors be part of the return type via Result or Option) solved an entire class of problem. Doesn't mean that there aren't others of course. But surely this is a win?

>inb4 it makes the code very complex with nested return type Result,ReadError>, ParseError>

Then it was just hidden from you before. The complexity had always been there, it just never occurred to you that it can happen.

Re: Unchecked Java: Say goodbye to checked exceptions

#185

Post by anon-3988 » Fri, Jul 14, 2023, 3:10 AM UTC

The_Colonel wrote: post #29

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. Which is bad. In 99% of cases I have no specific error handling for the given problem. Just let the process crash or be handled by application server / framework. Representing these kinds of error conditions in the code which I have no interest in handling is just noise.

In Rust you can just do "let value = result.unwrap()".

Re: Unchecked Java: Say goodbye to checked exceptions

#186

Post by wvenable » Fri, Jul 14, 2023, 3:11 AM UTC

breadwinner wrote: post #160

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…

That's how you do it in C#... See InnerException [1]. What a good programmer would do is to throw a new exception, and fix the callers to handle the new error. https://learn.microsoft.com/en-us/dotnet/api/system.exceptio...

That assumes you have control over the callers. If you're writing a library, you don't. Checked assumptions are incompatible with polymorphism and even just basic abstraction afforded by functions. One can't arbitrarily change an implementation without changing the signature and breaking all the callers.

The vast majority of cases, direct callers can't properly the handle the new error anyway. Callers either have to eat that exception, convert it (thus defeating the purpose of checked exceptions), or change their signature. Good programmers will change the signature and now every one of the callers of those methods have do the same thing. Ad infinitum.

Re: Unchecked Java: Say goodbye to checked exceptions

#187

Post by vbezhenar » Fri, Jul 14, 2023, 3:12 AM UTC

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 way is not hacky in any way and actually used by Java standard library itself, so I'd consider it "idiomatic".

Re: Unchecked Java: Say goodbye to checked exceptions

#188

Post by breadwinner » Fri, Jul 14, 2023, 3:17 AM UTC

pestatije wrote: post #171

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.

i do...if i ever get an IOException all i have to do is end the app, no need to deal with it in any way different than an unchecked exception https://phauer.com/2015/checked-exceptions-are-evil/

Check the root message of this thread... if you use unchecked exceptions you either crash or you swallow all exceptions. Both are evil, and checked exceptions are the solution.

Re: Unchecked Java: Say goodbye to checked exceptions

#189

Post by nradov » Fri, Jul 14, 2023, 3:19 AM UTC

int_19h wrote: post #178

nradov wrote: post #172

Earlier quoted context omitted.

Nope. Composition doesn't help when you have to implement an existing interface in order to make some API work.

If you're implementing an existing interface for that reason, it's because something else is going to be calling you. In which case throwing an exception that they don't expect is probably a bad idea, and relying on it just flowing through their code back to you is basically relying on implementation details in many cases.

No, that's not how it usually works in practice. Typically where this becomes a problem is in using an existing library as a middle layer in your application code. So you could catch your own additional exceptions, but the interface method signatures don't allow for that. Hence the need for ugly hacks like wrapping the checked exception in a runtime exception, then catching that and extracting the original exception. A real mess, but still better than the alternative of forking and modifying the library.

Re: Unchecked Java: Say goodbye to checked exceptions

#190

Post by chii » Fri, Jul 14, 2023, 3:27 AM UTC

erik_seaberg wrote: post #170

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.

stream.filter(p) requires wrapping checked exceptions in p, or altering the language so that they’re no longer checked. Same with Runnable.

or you start doing monads instead, where p operates on a monad (aka, the Optional type).

Unfortunately, this ends up propagating out and your entire code base needs to also do this. Tho i reckon it will make your code better in the future, for a short term/temporary pain converting/adding breaking changes etc.