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

271–280 of 297 posts

Re: Unchecked Java: Say goodbye to checked exceptions

#271

Post by 411111111111111 »

bheadmaster wrote: post #215
breadwinner wrote: post #156

Earlier quoted context omitted.

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.

Their comment was the one that this thread is bases on. They're merely pointing out that the original comment already gave an example why its a mess.

I disagree with their point though, in java the lib would've probably just converted the exception to a runtime exception so the API doesn't change...

Re: Unchecked Java: Say goodbye to checked exceptions

#272

Post by breadwinner »

colanderman wrote: post #192
breadwinner wrote: post #188

Earlier quoted context omitted.

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.

That's only possible if your code is 100% correct. Sometimes, your logic is flawed. A condition occurs which you erroneously deduced not to be possible. Unchecked exceptions are the necessary manifestation of these unforeseen errors. Catching them is pointless, what will you do with them? Dynamically fix the logic of your program? What can be the reasonable response to "index out of bounds", try a different index? [1…

Some errors are recoverable, some are not. When recoverable errors are possible you want to know what those errors are. If you don't then you will crash when you could have recovered. And that's the reason for writing down the list of possible exceptions where recovery and retry are possible (aka checked exceptions).

When recovery should not be attempted (example: "index out of bounds") then you don't want to declare or catch the exception, and that's when you use a subclass of RuntimeException in Java.

Re: Unchecked Java: Say goodbye to checked exceptions

#273

Post by phillipcarter »

interlocutor wrote: post #269
phillipcarter wrote: post #265

Earlier quoted context omitted.

Yes, not a good language designer responsible for (checks notes) one of the most-used and most-loved programming languages on the planet.

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.

Re: Unchecked Java: Say goodbye to checked exceptions

#274

Post by jitix »

adamwk wrote: post #150
jitix wrote: post #136

Earlier quoted context omitted.

You’re both right and wrong. Checked exceptions slow down development, make code ugly and in my theoretical opinion are an anti-pattern that should never be used. However in small to mid sized enterprise software companies with average developer talent it’s important to keep boundaries (and blame) clear. In the scenario in question, the CTO will blame OP and make them work the weekend to diagnose/fix it, so wrapping…

But even with unchecked exceptions, the exception value or description will still show up in the logs. I don’t understand how checked exceptions save you from a tyrannical CTO

Good point, but in my experience siloed teams (often if different continents) usually don’t standardize on error messages and codes, and a vague message like “Invalid name” doesn’t indicate which layer the message is coming from.

From operations’ point of view the bug will be pinned on the owner of the service that is returning the JSON to the client/app and it’s up to them to trace it down the layers. A hierarchy of wrapped exceptions helps with that. Kind of like saying “I can’t do it because XYZ didn’t do what they were supposed to do”. So low key corporate blame game in code.

I know that the usual HN crowd doesn’t work at/know about companies that follow this, but this pattern is way more prevalent in the broader “IT” industry esp among offshore centres.

Re: Unchecked Java: Say goodbye to checked exceptions

#275

Post by rrobukef »

colanderman wrote: post #195
pestatije wrote: post #171

Earlier quoted context omitted.

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/

A better example for IOException is network errors. If your socket dies, your code should attempt to reopen it! It should report to the user if it can't! Moreover, it's good that code nearest the site where the exception is thrown handles the error, as only it has context for what's going on at the time. Code further up the stack won't have any clue what this random IOException might relate to. If you're confident th…

But with abstractions you can have many more functions not handling the error before you get to the actual context.

Is it worth it to thread the IOException through the network layer, then the HTTP-client library, then then business serialisation up to the actual context?

I don't want a dozen checked exceptions. (and with this approach socket-limitations and connection loss should get a different exception.) I also don't want catch and rethrow. Unchecked+checked+docs+crashes are a measured approach.

Re: Unchecked Java: Say goodbye to checked exceptions

#276

Post by blackoil »

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 would say he is one of the better language designers. Unlike many language designed by theorists and academics, he understands how the engineers are using the language and how a feature is used/abused and develops around it.

Re: Unchecked Java: Say goodbye to checked exceptions

#277

Post by riku_iki »

masklinn wrote: post #209
riku_iki wrote: post #146

Earlier quoted context omitted.

The issue with checked exceptions in Java is that they are not supported in java lambda syntax and library functions.

More generally the problem of checked exceptions in Java is that they are not supported by Java. That was an issue right from the start, and it only got worse as the type system got richer.

> More generally the problem of checked exceptions in Java is that they are not supported by Java.

would you elaborate this statement?

Re: Unchecked Java: Say goodbye to checked exceptions

#278

Post by bedobi »

jbverschoor wrote: post #238
bedobi wrote: post #91

Earlier quoted context omitted.

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

> Any proper course or tutorial will tell you to catch specific exceptions

any real world library or application will catch Exception e, catch checked exceptions and turn them into unchecked ones etc etc

Re: Unchecked Java: Say goodbye to checked exceptions

#279

Post by bedobi »

kaba0 wrote: post #83
titzer wrote: post #44

Earlier quoted context omitted.

Situations vary a lot. In general there's no guarantee that a far outer scope is going to know how to deal with errors from deep inside some nested calls except for some very general logic, like failing a whole operation.

Even more commonly, there is no meaningful error handling to be done at a layer above the call.

I don't mean to be uncharitable but it seems like most exception advocates here don't really understand the case us functional error handling advocates are making. We don't advocate handling errors at every level. They're usually sent to the boundary layers of the system, eg the http resource layer, and folded there into http responses.

Re: Unchecked Java: Say goodbye to checked exceptions

#280

Post by wvenable »

breadwinner wrote: post #268
wvenable wrote: post #186

Earlier quoted context omitted.

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…

You can have multiple implementations of database drivers, but they all throw a subclass of SQLException. So yes, polymorphism is certainly possible. And when you get a SQLException (for example SQLIntegrityConstraintViolationException), you don't want to just crash, or display whatever error message the database gave you... you want to, at the very least, provide guidance to the user on what corrective action to tak…

That's an extremely contrived example. What if now you want to do a NoSQL solution? Or a flat file?

But really the problem is actually far worse than that. Checked exceptions are brittle under any kind of implementation change. If you have a function that calculates a rate just using arithmetic. But tomorrow it loads a flat file. And next week it uses SQL. And in a month it calls a web service. As a consumer, this is none of your concern -- that's the whole point of abstraction. It's even worse when dynamic (polymorhphism) or functional (external code calls you).

What's the recovery from a SQLException anyway? How does that give you enough detail to do anything? You say SQLIntegrityConstraintViolationException but that's not the same type. Why does it matter that you declared it a SQLException over just Exception in that case?

Post reply on HN