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

291–297 of 297 posts

Re: Unchecked Java: Say goodbye to checked exceptions

#291

Post by int_19h »

nradov wrote: post #189
int_19h wrote: post #178

Earlier quoted context omitted.

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

That is exactly my point - when you have a middle layer written by someone else sandwiched between parts of your code, assuming that any random exception you can throw will flow through (or, for that matter, that there even is a "through" in many cases - e.g. if the library makes some part async) - is relying on implementation details of said code.

Re: Unchecked Java: Say goodbye to checked exceptions

#292

Post by Supermancho »

skissane wrote: post #283
Supermancho wrote: post #154

Earlier quoted context omitted.

> I hate checked exceptions when they force me to handle an exception which I know is impossible given the arguments passed to the method. If I want to ignore a set of exceptions, I have the option to catch(Exception e) {} signaling that I recognize the risks that have been explicitly communicated by the API (that throws). An @IgnoreExceptions annotation would help dump the 5? boilerplate lines. The unknown risks for…

I've seen checked exceptions cause numerous bugs. Why? Because they encourage you to put catch clauses everywhere , and a lot of developers don't know how to write them properly (and even the best developers sometimes make mistakes that slip through the cracks). A common result of this is that a bug causes an exception, but the catch clause loses information about the original exception (such as by logging it without…

> I've seen checked exceptions cause numerous bugs.

I've seen quite a few in for-loops, so I'm not sure that's tracking for me.

> Why? Because they encourage you to put catch clauses everywhere

Java forces you to handle author-specified error conditions (CS error), but jr developers do tend to create their own more often than necessary.

While I agree that a global exception handler is good practice for Spring applications, individual exception handling is very common and important to modern software. eg If Web APIs get more complex (multiple datastores), you find you don't want to bubble everything up. I get a request, want to check a cache (which might throw) then look it up in a DB (which might throw) then look it up in a file (etc), then return a response.

I do wish I could handle exceptions simpler than making the choice to add 4 lines (+ any actual logging, etc) or blackhole-traveling through the stack to add checked exception signatures everywhere (code AND tests).

Re: Unchecked Java: Say goodbye to checked exceptions

#293

Post by unscaled »

int_19h wrote: post #181
unscaled wrote: post #157

Earlier quoted context omitted.

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…

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

I wholly agree with this sentiment. Rust Result types where also excruciatingly inconvenient to use at the early days, but Rust gradually added facilities to make it better: first the try! macro and if-let, then the ? operator and finally let else. Together with crates like anyhow, thiserror and eyre, error handling became a lot better. I don't use Swift a lot, but it also seem to have iterated on its error handling.

In the 27 years of its existence, Java did very little to improve exception handling facilities. It added exception chaining in Java 1.4 and catching multiple exceptions in Java 7, that's it. I'm not picking up specifically on Java here - I think many languages neglect exceptions or error handling. Go is also an instructive example of a language that chose a non-exception-based error handling mechanism that the designers claimed to be superior, but failed to add ergonomics to that. This is not for the lack of trying though: the Go team tried to fix this issue multiple times, but there are very vocal parts of the Go community who opposed any kind of ergonomics, in favor of "explicitness" (as if explicitness means "error-prone boilerplate"). I would give the Go team full score for seriously trying.

I give them less score on the composition-over-inheritance part though. Go is one of the languages that has objects (structs) and interfaces, but disallows inheritance, but it doesn't provide any mechanism for automating delegation. Kotlin has shown that this is possible and even quite simple. It's not one of these languages features (like method overloading, type classes and generics) that carries a lot of corner cases and complexity that you have to deal with.

Re: Unchecked Java: Say goodbye to checked exceptions

#294

Post by peterashford »

phillipcarter wrote: post #273
interlocutor wrote: post #269

Earlier quoted context omitted.

Do you mean Turbo Pascal? He didn't design it, Niklaus Wirth did. Or do you mean C#? James Gosling designed most of that (C# got its start by copying 90% of Java). Do you mean TypeScript? That's mostly JavaScript.

You're certainly entitled to your opinions.

Those are facts

Re: Unchecked Java: Say goodbye to checked exceptions

#295

Post by skissane »

Supermancho wrote: post #292
skissane wrote: post #283

Earlier quoted context omitted.

I've seen checked exceptions cause numerous bugs. Why? Because they encourage you to put catch clauses everywhere , and a lot of developers don't know how to write them properly (and even the best developers sometimes make mistakes that slip through the cracks). A common result of this is that a bug causes an exception, but the catch clause loses information about the original exception (such as by logging it without…

> I've seen checked exceptions cause numerous bugs. I've seen quite a few in for-loops, so I'm not sure that's tracking for me. > Why? Because they encourage you to put catch clauses everywhere Java forces you to handle author-specified error conditions (CS error), but jr developers do tend to create their own more often than necessary. While I agree that a global exception handler is good practice for Spring applica…

> I've seen quite a few in for-loops, so I'm not sure that's tracking for me.

The difference is that for-loops are almost an essential language feature – the vast majority of languages have them (or a close equivalent), and they make certain algorithms a lot easier to state clearly. Sure, there are some languages which lack them, but they tend to be either languages with non-mainstream paradigms (such as pure functional or logic programming languages) which put all the emphasis on recursion instead, or else really old legacy languages which predate the development of structured programming (such as pre-1980s versions of COBOL–modern COBOL versions have for loops)

By contrast, almost nobody considers checked exceptions an "essential language feature" – languages which lack them vastly outnumber languages which possess them, indeed, Java stands out as the only major mainstream language to possess them

Given the argument "this unusual inessential language feature causes more bugs than it prevents", the response "this essential language feature which the vast majority of languages have sometimes causes bugs too" isn't very convincing

Re: Unchecked Java: Say goodbye to checked exceptions

#296

Post by menaerus »

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?

Although theoretically possible there will be rarely any C++ codebase that will use exceptions for control flow.

Re: Unchecked Java: Say goodbye to checked exceptions

#297

Post by menaerus »

masklinn wrote: post #210
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…

> 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 They’re literally the only way to report ctor errors. > What Zig and Rust have as error handling mechanisms C++ has them too. Only in the most reductive way that all langages are turing complete, in which case Java has them as well.

> They’re literally the only way to report ctor errors.

The point being? Please go find me a codebase which wraps object instantiation in try-catch clause if that's what you are trying to say. I haven't seen any.

Anyway, for that reason constructors are always written so that they cannot fail in hideous ways, and if there is no other way around it there is always 2-phase initialization (personally I think it's an anti-pattern).

> Only in the most reductive way that all langages are turing complete, in which case Java has them as well.

Nonsense. Zig AFAIU abstracts error types as some sort of integer enums while OTOH Rust has Result. C++ has both of those mechanisms baked either into the language (enum) or standard library (std::expected, std::optional).

Post reply on HN