Exception handling and logging strategies
I know very well that this seems to be a never-ending story with a lot of different opinions. I also have searched the forum and found links like these (I have read a lot about exception handling and logging - this is just two links that made me think lately):
However I want to give it a (new) try:
What I read so far is the following best practices:
- When the program fails it should fail early and noisy.
- Exceptions should be handled at top level.
- As an alternative exceptions should be handled immediately, logged and re-thrown as new (handled or unhandled exception - several opinions here).
I have my problems with these best-practices. Here are the reasons:
- A program that aborts completely on a failure might be ok for a commandline tool but not for a service running on a server or for a GUI application.
- Why should I handle an error at top level where I definitely cannot really decide how to probably fix the error - this must be done at the component level where the error occurs. - Example: If a file containing some defaults cannot be found I could probably fix it by searching at an alternative location - this must be handled on component level and in such cases a warning should be enough to be reported to the top level.
- Handling and rethrowing exceptions is a lot of additional work - as it is recommended to use your own application specific exceptions, should I create a separate exception for each error type? - Again much work
When it comes to error handling it comes to logging also. It is nice that log4j does support a lot of destinations for logging but from my experience logging (and I am talking about real warning, error and debug logging here and not about "statistical" information that is created whenever a new job was processed, a new file has been created in some content store etc. - this for me is a different thing which for some applications is interesting). Logging is only relevant when analysing buggy behaviour and as many problems (from my experience) come together with network problems the only reliable logging is a local file at the host where the app runs. So from this point of view the java internal logging seems to be enough for me (although many complain that it is not sufficient).
However, with the standard java logging features there does not seem to be log handline features like log rotation and so on (or maybe I didn't find them so far).
What I wondered is why e.g. NetBeans when handling exceptions automatically creates a line like this:
although I read that Logger.getLogger... and all reflection methods (MyClass.class.getName - is reflection IMHO) eats a lot of performance.
Logger.getLogger(MyClass.class.getName()).log(Level.SEVERE, null, ex);
I am only a beginner in Java but I am working in software development for many, many years (at least more than 15) working with different programming languages so I do have experience in software development. According to the "forecasts" I do expect many annoyances (see problems above) from the best practices written at other places.
And actually I do think that others must have experienced similar problems.
There is an approach I do think of currently:
- Writing my own error handler (which can be done with Java core features) that logs to a file and either (in addition to logging to the file) add the errors and warnings to an internal error or message collection in memory.
- Handle each error on lowest level where can be handled and log it.
- Have methods getErrorCount and getWarningCount in my error handler. Those can be checked at beginning or after critical operations in code.
- Have methods clearErrors and clearWarnings in my error handler so that I can reset them when I handled them (tried a workaround, have retried or have shown the errors to the user).
With this approach I think I could solve the problem of error handling on upper level but anyway can check also on higher level if errors occured or not.
Please tell me about your experiences, solutions and opinions how and when to handle errors and when not and how to deal with logging.