magic_lobster_party
I think try catch often leads to messy code. It breaks the control flow in weird ways. For some reason we’ve collectively agreed on that goto is a bad idea, but we’re still using exceptions for error handling.
Consider this example:
try {
File file = openFile();
String contents = file.read();
file.close();
return contents:
} catch (IoException) {
}
Say an exception is triggered. Which of these lines triggered the exception? It’s hard to tell.
We might want to handle each type of error differently. If we fail to open the file, we might want to use a backup file instead. If we fail to read the file, we might want to close it and retry with the same file again to see if it works better this time. If we fail to close the file, we might just want to raise a warning. We already got what we wanted.
One way to handle this is to wrap each line around a separate try catch. This is incredibly messy and leads to problematic scopes. Another way is to have 3 different exception types: FileOpenException, FileReadException and FileCloseException. This is also incredibly messy.
Or we can include the error in the return value. Then we can do whatever we want programmatically like any other code we write.
What I’m saying is that it’s hiding too much of the control flow.
Compare it with this code:
public double calculateCommision(Sale sale, Contract contract) {
double defaultCommision = calculateDefaultCommision(sale);
double extraCommision = calculateExtraCommision(sale, contract);
return defaultCommision + extraCommision;
}
This is about the same number of lines, but it communicates so much more about the control flow. It gives us an idea which data is involved in the calculations, and where we can find the result of all the calculations. We can make assumptions that the functions inside are independent from each other, and that they’re probably not relying on side effects.
This is also against clean code examples, because Uncle Bob seems to be allergic against function arguments and return values.
Academia has a disconnect with the industry when it comes to coding practices. Most teachers haven’t much industry experience. They don’t know how it is to maintain a 10 year old project using SOLID and clean code principles.
They just teach whatever has already been in the curriculum for decades. They don’t know that whatever they’re teaching is actually harmful in the industry.
I heavily disagree it’s easier to write good code if you follow clean code. Especially if you follow his examples throughout the book. Most of his examples are just over engineered messes held together by side effects (even if he says side effects is a bad thing).
If he can’t write good code by following clean code, why should you? He even picked the examples himself and failed!
These kind methods hide too much.
Where can I find the commissions these methods calculated? Does extra commissions depend on the calculations of default commissions? Do I need to calculate default commissions before calling hasExtraCommisions? What happens if I calculate extra commissions if hasExtraCommisions return false?
There are so many questions about this code that should be immediately obvious, but isn’t.
