Hacker News Reader

> Sometimes I've even had to throw a different type of exception than declared by an interface method and was left to either refactor tons [...]

I see that this is inconvenient. This might be the essence of the whole thing here. It is way worse than adding a new argument to a function!

1. There is no way to overload a function with different Exception clauses.

2. You not only need to touch the call sites but also parts of the stack that led to the call sites.

> I've had to write code to open a file that I know will always exist

How can you ever be sure a file exists? I can be sure a function or a variable exists if I declared it. Files can be manipulated by other processes, USB drives are ejected, etc. You can never be sure they stay where it was. Even if I created the file one line above, I technically still have a potential race condition.

> For functional programming languages, I think it's a lot more convenient to not have checked exceptions.

There is a clear tradeoff here. E.g. when writing python or bash scripts I seldom care to catch errors. Let it crash fast and return a stack trace. For production grade software you usually want to much more careful and handle exceptions explicitly. Checked exceptions are clearly targeted for the latter.

> How can you ever be sure a file exists?

Well I can't ever be sure, but the example I'm thinking of is looking up a config file on the file system that was copied there by a deployment script. If it didn't exist, a RuntimeException failing the application would be entirely appropriate.

If I was checking for a file on a USB drive or some other source, I'd very much have a try-catch. Do I need checked exceptions in this case? Still debatable in my opinion.

WRT checked exceptions targeted for production grade software, curious what you think about the (lack of) checked exception handling in Java 8 lambdas.

> I can't tell you how many times I've had to write code to open a file that I know will always exist and have to write an empty try-catch.

How do you know that the file will always exist? I'm pretty sure you don't. The try catch shouldn't be empty. Now it's going to crash when you try reading or writing from the file so all you did was make it so it blows up with a less helpful error later.

That's an entirely appropriate failure mode for my case. If my app can't find an important file, then it should fail immediately, alerts then go off, dashboards are bleeding, ops is getting paged, etc.

You did not get that failure mode. If you want to fail at file not found, wrap it in a RuntimeException or IllegalStateException or something. You don't even have to create a new class, just use one of these 2 built ito Java.

For example: you store a conversion factor in you config file (eurostodollars=1.12 or whatever).

If you have an empty catch block, you now have a null Reader object or something. Next read will throw an IOException, which you also swallow and you now have an uninitialized config value. Except that one will be zero instead of null.

500 km further in your code, a month after you started the app, that zero gets used in your code.

  amounttopay+=eurostodollars*euroamount;

This will not fail immediately either. No, it will do something weird. In the best case, you crash for a really weird reason. More probably, you send out a file or web call or ... with insanely wrong data. Bonus points if you sign it with a private key, then you're legally bound by whatever nonsense you happened to promise. The next program in the chain might sit either in your company or not. It will swallow your garbage date wholly, do no checking of its own as this no-error-checking culture is pervasive. It will either crash and or do further damage. When the shit finally hits the fan, it will be a containerload of shit instead of a mouse dropping.

I saw this kind of scenario again and again. No , the app cant possibly start without database, that never happens, and anyway the next user will notice the empty database. Except after power failure in the middle of the night, when the database is still booting up while your app is reading the config from it. When business hour start, everything seems fine. Until it isnt.

Nothing about checked exceptions inherently prevents the failure scenarios you list, particularly the one about the power failure.

Also, I gave a bad example for empty try catch. In this case, I would want a runtime exception thrown. Apologies for misleading the conversation.

In that case, you avoided disaster and I'm starting to agree with you.

Correct, this was about swallowing errors instead of rethrowing/handling.

Checked exceptions are good if you want to be sure your caller does something when things go south. Some examples from my experience:

* Most things that should be told to the end user, i.e. Business Exceptions. E.g. a webshop user tries to buy something but your stock has been emptied why he was deciding if he should buy or not.

* Follow-up after a modification: If you wrote half a file, you can delete it in your catch IOException instead of letting it linger around. My company has a tendency to pick up and process any file found in an output directory as soon as you release the file lock. But just not filling your disk is good enough for me as reason.

if the problem is that the file is missing, FileNotFoundException sounds like the most useful one

an empty try catch wont necessary make that happen. It could countinue with the assumption that it has a File when it doesnt, corrupting further things in its (uncontrolled) way out.

Yes that's a bad example for an empty try catch, in that case one should throw a runtime exception. Apologies for the misleading example.

That's the gig economy perspective. What happens when you are deploying software on someone else's computers? There are often no "ops" and no "dashboards" but a single technically unskilled user trying to get some work done.

Don't get me wrong, I also think that Java's checked exceptions are not really useful but your argument is very one-sided.

I don’t get it. Even if you think a file can always exist (bit of an amateur assumption, btw), then why would you wrap it with try/catch at all?

My point exactly.

> and have to write an empty try-catch

I end up converting checked exceptions to runtime exceptions all the time:

    try {
        ...
    } catch (RuntimeException e) {
        throw e;
    } catch (Exception e) {
        throw new RuntimeException(e.getMessage(), e);
    }