4 ms·
You need to help train your coworkers to write better code :) Point this thread out to them. Seriously, Java doesn't force bad programmers to write good code.
by breadwinner 3y ago
You need to help train your coworkers to write better code :) Point this thread out to them.
Seriously, Java doesn't force bad programmers to write good code. It just enables good programmers to write good code.
- Kamq 3y agoI will acknowledge that this wasn't the best code (or the best programmers). I will also cede the point that you can write good code in Java. But my point was that Java wouldn't have enforced the situation to be a compile error, not that you can't write good code in Java. I maintain this point, and I think it's true for the average java project. If you're getting these benefits from Java, it's the intersection of Java and your team's or your organization's culture, not purely from Java. It's possible for you to gain this benefit and for checked exceptions to have still failed out in the wider world of the average Java project.
- xen0 3y agoAnd a lack of checked exceptions means good programmers can't write good code? So good code may only be written in Java? No... I don't think so. Checked Exceptions are at best, just a 'hey, are you sure that's right thing to do here?' and at worst, an additional source of rigidity in your code that blows up the scale of a minor change.
- breadwinner 3y ago> And a lack of checked exceptions means good programmers can't write good code? Right, and that was my point at the top post in this thread.
- xen0 3y agoWait, you seriously hold that position!? As in, only Java permits good code?
- breadwinner 3y agoEach language has its strengths and weaknesses. In the case of exceptions Java gets it right, C# doesn't. There are other aspects that C# does better than Java.
- anonymoushn 3y agoThey also have to throw RuntimeException if they want to use APIs that accept functions and therefor specify which checked exceptions those functions are allowed to throw, like Streams.
- crabbone 3y agoThat is not better code. Couple of try-catch-catch-catch-...-catch cases in a function that would otherwise be 2-3 lines long makes for an awful code. Also, imagine a situation when an iterator throws an exception. Or you wanted to write f(g()) but now you can't and have to do: try: T t = g(); catch E1: ... catch En: ... f(t); Now it takes a much greater effort for the reader to figure out what's going on. It's also tempting to allow some exception cases to succeed so, f(t) is reached even if there was an error. Because these two code pieces are now far apart, it's possible that later edits will introduce bugs because the programmer didn't see that either f(t) is reachable even if g() failed, or accidentally made it reachable when it shouldn't have been. Bottom line, it makes human errors more likely.
- mkleczek 3y agoThis is only because you use exceptions incorrectly. You can (and should) write: try { final var fResult = f(g()); //do something with fResult } catch (E1 e) {...} catch (En e) {...} That's the main idea of exceptions in all languages: main flow is kept together and exceptional flows are separate.
- im3w1l 3y agoI think the issue with this pattern is that either we don't care about went wrong, we want to treat all errors the same way, and then having n catch clauses is overkill. Or we do care about went wrong, and in that case the exception type is not enough to identify the issue, as often multiple lines in the try block will throw the same exception type.