I've been looking for information on the Internet about where and how to log exceptions: On the top level or the bottom level? I've found very useful information, but also some which has caused me even more confusion.
My current plan consists on catching exceptions on the top level. Then, if it's either a runtime exception or a checked exception about which the user can't do anything, I log them. If it may be fixed in some way by the user, I show him an alert so he can take a convenient decision.
In my opinion, logging exceptions is a very special and risky case of logging because exceptions are made to interrupt the normal flow. If you simply catch and log them on the bottom level, the execution will continue as ususal on the higher levels of the call stack and may lead to an inconsistent behaviour. For example, if the method returns an "int" but fails, it would need to return some kind of special value (-1?), and then you should give it a special treatment in the caller method. But if the whole range of "int" values were considered right values, then it would be an absolute mess, Right?
I also have read that logging on the bottom level and re-throwing (with or without wrapping the exception) is bad idea and is one of the so called "anti-patterns". Mainly because it could cause that the same error got logged many times.
So, What's the way to log exceptions on the bottom level? Is it feasible? Because I can't find a reliable way to do such thing without interrupting the execution "by hand".
After some weeks experimenting I've decided to wrap the exceptions with exceptions created specifically for my application, and log them on the top level only. I'm loving this approach because I'm not losing detail (I simply have to check the whole exception stack trace), and am being able to concentrate the error logging in a single place.