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

261–270 of 297 posts

Re: Unchecked Java: Say goodbye to checked exceptions

#261

Post by kaba0 »

skissane wrote: post #112
breadwinner wrote: post #109

Earlier quoted context omitted.

Certainly you can intentionally break it, but then that's on you.

A person can also accidentally break it - by adding some new code which contains a bug which causes an unchecked exception or error to be thrown (e.g. NullPointerException, ArrayIndexOutOfBoundsException, StackOverflowError, etc). Checked exceptions do nothing to protect against those kinds of mistakes, which in my personal experience are vastly more common than whatever mistakes for which they may provide some prote…

Everything can fail at every time — that’s part of the art of programming to discern which error conditions are meaningful to be included in the signature, and which are not.

Re: Unchecked Java: Say goodbye to checked exceptions

#262

Post by colanderman »

rixed wrote: post #207
colanderman wrote: post #197

Earlier quoted context omitted.

> You do not wrap checked exceptions in an unchecked one... unless you are a really bad Java programmer. I disagree -- this is the correct thing to do if you believe it is not possible for the checked exception to occur. (Catching it is wrong -- what would you do to correct something which you believe not to be possible? Forcing the caller to handle it is wrong -- if you don't know what to do with it, they sure won't…

> if you don't know what to do with it, they sure won't! Actually no. For instance, the caller at some point up the stack may know if something is worth retrying.

Then you should unwind your state correctly and rethrow as a checked exception stating as much. If there levels up the stack I see a random unexpected "IO Exception" from your library I have no idea whether you are still in a valid state to retry. If I instead see a "Foolib Request Aborted: reason IO Exception" I know you've written logic to handle that case, and I know that retrying is appropriate.

Re: Unchecked Java: Say goodbye to checked exceptions

#263

Post by colanderman »

Hermel wrote: post #222
colanderman wrote: post #197

Earlier quoted context omitted.

> You do not wrap checked exceptions in an unchecked one... unless you are a really bad Java programmer. I disagree -- this is the correct thing to do if you believe it is not possible for the checked exception to occur. (Catching it is wrong -- what would you do to correct something which you believe not to be possible? Forcing the caller to handle it is wrong -- if you don't know what to do with it, they sure won't…

> I disagree -- this is the correct thing to do if you believe it is not possible for the checked exception to occur. If it is not possible to occur, then it should not be part of the API. The only time I rethrow a checked exception as an unchecked exception is when the code is still under construction. The default of the eclipse code generator is to log and ignore caught transaction. I think wrapping into an uncheck…

Example: validation of serialized data followed by deserialization. Deserialization properly should throw a checked exception, since invalid serialized data is very much a thing. But in this case the serialized data is known to be correct (because it passed validation). The checked exception will never occur, and were it to, there's nothing we could do about it, because it reflects a logic error, same as out of bounds array access.

The algebraic data type equivalent of this shows up all the time in functional code -- unwrapping a result type you know can't be Error/None/etc. because of logic. You don't rewrap it and force the caller to deal with a case which logically cannot occur; instead you throw an unchecked exception.

Re: Unchecked Java: Say goodbye to checked exceptions

#264

Post by smrtinsert »

breadwinner wrote: post #155
jabiko wrote: post #117

Earlier quoted context omitted.

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…

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

> You do not wrap checked exceptions in an unchecked one... unless you are a really bad Java programmer.

That's not a given. It's perfectly fine to handle a checked exception via some custom runtime. The nice part is your your code base was given a chance to handle the key exceptions of this particular api all from your ide without you having to refer to documentation etc.

Re: Unchecked Java: Say goodbye to checked exceptions

#265

Post by phillipcarter »

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.

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

Re: Unchecked Java: Say goodbye to checked exceptions

#266

Post by masklinn »

rogerkeays wrote: post #242
clhodapp wrote: post #200

Earlier quoted context omitted.

I'm completely serious in the sense that you could do that and really would in some situations. You might do it because you want to factor the handling of the different result cases out to another function.

You don't think it would limit the independent use of f()?

No? Surely if f() takes a full result (including error condition) it's because there's something it wants to do with that?

Re: Unchecked Java: Say goodbye to checked exceptions

#267

Post by masklinn »

josefx wrote: post #230
hedora wrote: post #165

Earlier quoted context omitted.

Checked (and unchecked) exceptions create an exponential number of control flow paths. Consider: try { throws_a(); r = grab_resource(); throws_b(); r.throws_a(); } catch (a) { r.release(); // oops; null pointer some times } catch (b) { try { r.release(); } catch (a) { // nooo.... } } finally { if r != null { r.finalize() // use after release (sometimes) r.release() // ??? } } There is plenty of academic literature sh…

> r.release(); // oops; null pointer some times Quite sure Java would prevent that if r was never assigned. Also most languages provide cleaner try-with-resources or RAII style lifetime management so you don't actually end up with that kind of spaghetti code unless you actively go out of your way to be bad at programming.

> Also most languages provide cleaner try-with-resources or RAII style lifetime management so you don't actually end up with that kind of spaghetti code unless you actively go out of your way to be bad at programming.

Context managers (try with resources) specifically don't work at all when release is conditional e.g. open a file, need some post processing, need to close the file if the post-processing fails but return it if it succeeds.

Defers don't either, unless you have a specialised one (e.g. zig's errdefer).

Actual RAII (aka affine types) does work, but adding that to a GC'd langage after the fact is a huge undertaking and increase in complexity, because the interaction between affine and normal types is fraught.

Re: Unchecked Java: Say goodbye to checked exceptions

#268

Post by breadwinner »

wvenable wrote: post #186
breadwinner wrote: post #160

Earlier quoted context omitted.

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…

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 take. And in some cases the program can automatically take corrective action. And that's the reason for writing down a list of possible exceptions where recovery and retry are possible (aka checked exceptions).

Re: Unchecked Java: Say goodbye to checked exceptions

#269

Post by interlocutor »

phillipcarter wrote: post #265
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.

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.

Re: Unchecked Java: Say goodbye to checked exceptions

#270

Post by vips7L »

SomeRndName11 wrote: post #246
vips7L wrote: post #99

Earlier quoted context omitted.

It’s honestly the worst compromise. You can trivially ignore any error in Go and they don’t contain contextual information about the call stack.

ABility to ignore errors is a plus in fact. You can skip trivial non-critical problems and carry on without crashing the whole app, like it is normally done in C and C++.

It would be if you would have to explicitly opt into it via an ignored variable like _ or something. But currently with go you can accidentally ignore the error when you don't mean to.
Post reply on HN