3 ms·

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

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.

hyperman1 8y ago
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.
- leothekim 8y ago
  Nothing about checked exceptions inherently prevents the failure scenarios you list, particularly the one about the power failure.
  - leothekim 8y ago
    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.
    - hyperman1 8y ago
      In that case, you avoided disaster and I'm starting to agree with you.
  - hyperman1 8y ago
    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.
- 8note 8y ago
  if the problem is that the file is missing, FileNotFoundException sounds like the most useful one
int0x80 8y ago
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.
- leothekim 8y ago
  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.
foepys 8y ago
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.

hyperman1 8y ago

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.

leothekim 8y ago
Nothing about checked exceptions inherently prevents the failure scenarios you list, particularly the one about the power failure.
- leothekim 8y ago
  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.
  - hyperman1 8y ago
    In that case, you avoided disaster and I'm starting to agree with you.
- hyperman1 8y ago
  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.
8note 8y ago
if the problem is that the file is missing, FileNotFoundException sounds like the most useful one

int0x80 8y ago

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.

leothekim 8y ago
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.

foepys 8y ago

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.