Hacker News Reader

Comment by invalidname | Hacker News Reader

Let's say I write an API for handling IO. DB or File or networking or anything really.

I get a failure, what do I do?

I can throw an exception, but this is important how do I know the user of my API will actually do the cleanup after me. I can't do the cleanup since this is a part of an API not the actual usage of the API. How can I give the user of this API the right set of hint that "you need to pay attention to this" without worrying too much.

Checked exceptions are that. A large part of the problem is when people use them for things that aren't important, but when they are important I can just declare a "throws" and know that someone will handle the exception along the chain.

With runtime exceptions I have no guarantee.

View on HN

Any chance you have a code/pseudo code example of this?

My naive take on this would be “just use raii/closable”. (But easily and likely, I misunderstood)

Let's say Java had no checked exceptions. I could just write IO code without doing a try since no one is forcing me to check anything.

But let's go further. Let's say I have an API x(). This API accesses my database as part of a larger transaction.

I invoke x() and it fails with an SQLException which is declared. I can revert the transaction or I can choose to retry x(). The checked exception notifies me that there's an important decision I need to make at this point, cleanup is one option but in some cases there are more. Furthermore, cleanup isn't always enough. In a case of an IOException I'd often want to notify the user e.g. if the disk is out of space I want to show an error message somewhere...

> Let's say Java had no checked exceptions. I could just write IO code without doing a try since no one is forcing me to check anything.

Any decent C# linter will notice that the class exposes (IDisposable) and warn you that you should at least be wrapping it in a “using” block.

That's true for Java too. But that's only a part of the problem which is why I gave the second example.

Also, notice that a linter and a compiler error are different. I agree that people *should* always use a good linter and IDE. The reality is sadly far from that.

On its own, seeing ‘SQLException‘ in method signature, does not provide you with information: “this is part of bigger transaction, and you have ability and responsibility to retry or rollback”.

That will be part of lib documentation, which should be read & understood regardless of existence of checked exception.

No. The transactional context is something the caller to the API knows. The person implementing the API that might fail on the SQL call doesn't know what's going on. That's why we would let the exception propagate.

> That will be part of lib documentation, which should be read & understood regardless of existence of checked exception.

First, checked exceptions *are* documentation for the lib. The best kind of documentation.

Second, really?

I would love to live in your world where people read documentation and where we all perfectly update the docs for everything. But both sides of this equation leave a lot to be desired in my world.

I don't read the documentation of most changes to most libraries. If I did that I would never get anything done. I can't even keep up with every commit that goes into the project I'm running. There are too many changes and too much code (I'm talking 30+ non-trivial merges per day).

Reply on news.ycombinator.com