posted 10 years ago
I would also suggest not to "swallow" exceptions silently. Look at this:
If an exception occurs, it is printed to the standard output, where someone might read it (or not). However, since the catch clause doesn't throw another exception, the program flow continues, in your case by returning false. So, your method returns false in two cases:
there isn't the required eater in the database,there was an error trying to obtain the eater from the database.
However, these are vastly different situations, and the caller of your method has no way to tell them apart.
Generally, if an unexpected error occurs, it is best to allow the software to crash. This will definitely bring someone's attention to the problem, which can then be mended. If you allow your program to continue after an exception occurs, it is possible for a problem to go unnoticed for month, usually causing the application to generate wrong outputs all that time. It is unpleasant having to explain to your boss why your system crashed at the busiest time of the day, but it much more unpleasant having to explain that all monthly numbers for pas six months are wrong.
Only when the exception is anticipated and properly dealt with it is advisable to continue the flow of the application. In all other cases the best option is to simply throw an exception from all catch clauses (checked or unchecked, depending on your project's exception handling conventions) and have it dealt with at the topmost level. In really simple applications, this let the application crash. In more complicated ones there usually is (or at least should be) some sort of reporting system which will alert someone to the problem.