Comment by Animats | Hacker News Reader

Comment by Animats | Hacker News Reader

Automatic closeout remains a hard problem. "Defer" has the same problem as RAII - what if the closeout fails? Python's "with" clause, and how it interacts with exceptions, is one of the few constructs that can handle multiple closeout faults correctly.

Trying to get rid of exceptions seems to force workarounds that are worse than exceptions. C++ and Java exceptions were botched and gave the concept a bad name. Go's "panic" and "recover" are an exception system, but not a good one. Python comes closer to getting it right.

Key concepts for successful exceptions:

- A predefined exception hierarchy. Catch something in the tree, and you get everything below it. Python added this in the 2.x era, and it made exceptions usable. (Then they messed it up in the 3.x era, putting too much stuff under "OSerror".) This solves the problem of "Have I caught everything"?

- The case where a closeout event raises an exception has to work. This is hard. Attempts to get it right resulted in such horrors as "re-animation" in Microsoft Managed C++. It needs something like the Rust borrow checker model to make sure that object lifetimes are properly enforced on all error paths.

Hm. I actually love how Java does exceptions. I think a little better conventions around when to use checked vs unchecked might help but generally I'd rather checked exceptions be the norm than wholely absent.

What do you think is missing? My only ask would be syntax to capture an exception Future/Expression style for smaller use cases.

I think this is what you’re asking for with your last sentence, but I’m not sure so I’ll say it anyway:

My main gripe with Java’s checked exceptions is that there’s no way to bubble up a checked exception from inside a functional interface, because the function signatures differ. For example, if you want to close a bunch of files, you can’t do `files.forEach(file -> file.close())` if the call to close throws IOException — you need to use an iterator (which is longer) or catch and re-throw it as a RuntimeException (which is much longer). Libraries like JOOL can help here, but not completely.

It also doesn’t help that certain methods are declared as throwing exceptions that aren’t actually thrown, such as `ByteArrayOutputStream#close()`.

I used to argue in favour of checked exceptions, but once I switched to Kotlin, I realised that I didn’t actually miss them at all. However, my other favourite language (Rust) uses something a lot closer to checked than unchecked, so maybe I’m just writing different kinds of code on the JVM to let me get away with having this opinion!

Exception hierarchies are hard to get right. Java botched it too, making checked exceptions look bad.

I like Go's use of a single error type in most public API's. Combine with checked exceptions and you would have two kinds of functions: those that can fail and those that can't. It keeps the "what color is your function" problem to a minimum.

Java checked exceptions are based on CLU, Modula-3 and C++ exceptions clauses.

Naturally one just blames the one that actually got famous using them.

Java 7+ has everything you describe for Python 2.5+.

The problem in Java is checked exceptions, which can be frustrating -- either leading to try {} catch{ /* ignored */} or bubbling up the exception (probably preferable, but more work).

IDE support makes this nicer, and Java's tooling is certainly first-rate in my experience.

I try pretty hard to make the close-outs failsafe. It is very difficult to manage errors or recover once you have started closing resources. However, you are then left manually calling file.Flush (for example), which can easily be forgotten.

Yes. That's the argument for "with" type constructs.

Reply on news.ycombinator.com