5 ms·
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. Or had to add an unuse
by leothekim 8y ago
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. Or had to add an unused throws clause because an interface specified it. 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 of code to uselessly handle the new checked exception or throw a runtime one and catch it at the smaller number of callsites, or throw it as one of the declared checked exceptions that would not accurately describe the type of error to be handled. Anyone use Hibernate and see how many times an underlying SQLException got wrapped by a HibernateException?
For functional programming languages, I think it's a lot more convenient to not have checked exceptions because how they affect the composability of closures. Not saying it's impossible, but imagine having to add throws clauses to your .map and .filter chains.
- heinrichhartman 8y ago> 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.
- leothekim 8y ago> 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.
- choward 8y ago> 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.
- leothekim 8y agoThat'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 agoYou 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.
- wild_preference 8y agoI 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?
- leothekim 8y agoMy point exactly.
- wtetzner 8y ago> 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); }