Koen Aerts wrote:I like to put hardcoded strings first, so that you can avoid nullpointer exceptions. For instance instead of stringValue.equals("HI") I would do "HI".equals(stringValue). If stringValue == null, then the first example will throw an exception, while the latter will just return false.
Casper Bezemer wrote:That's true, and because it's all in an try catch anyway, the program will not crash into a runtime error.
Casper Bezemer wrote:But you guys don't understand! The try-catch is not for the NPE, it's for the IOException of the BufferedReader.
Casper Bezemer wrote:But you guys don't understand! The try-catch is not for the NPE, it's for the IOException of the BufferedReader. A NPE can never occur in my code
Mike Simmons wrote:Well, I would argue that there are times when it can be acceptable to catch a general exception type like RuntimeException
and there is business value in processing subsequent requests even though something went wrong with one of them. In such cases, it's imperative that we monitor the logs for errors, and fix them - but meanwhile we may still need to be handling new records, requests, etc.
The thing is, whenever we catch any sort of exception, we really have to think about exactly what happens after it's been caught. It's not enough to say it was caught, so it's OK. We have to look at where it was caught, and what code will get called right after that, and whether the code can successfully return to doing something useful.