Non tutti sono soliti loggare cosa sta succedendo durante l’esecuzione di un’applicazione. E questo e’ il MALE, c’e’ poco da dire! Altri invece, pur loggando, non sanno mai quando loggare come trace, debug, info oppure warning, e spesso si ritrovano ad usare uno solo di questi valori, assieme al canonico error per segnalare l’accadimento di disastri.
Ho trovato su questo post una guida che puo’ aiutare a decidere “dove va cosa”:
ERROR: something terribly wrong had happened, that must be investigated immediately. No system can tolerate items logged on this level. Example: NPE, database unavailable, mission critical use case cannot be continued.
WARN: the process might be continued, but take extra caution. Actually I always wanted to have two levels here: one for obvious problems where work-around exists (for example: “Current data unavailable, using cached values”) and second (name it: ATTENTION) for potential problems and suggestions. Example: “Application running in development mode” or “Administration console is not secured with a password”. The application can tolerate warning messages, but they should always be justified and examined.
INFO: Important business process has finished. In ideal world, administrator or advanced user should be able to understand INFO messages and quickly find out what the application is doing. For example if an application is all about booking airplane tickets, there should be only one INFO statement per each ticket saying “[Who] booked ticket from [Where] to [Where]”. Other definition of INFO message: each action that changes the state of the application significantly (database update, external system request).
DEBUG: Developers stuff. I will discuss later what sort of information deserves to be logged.
TRACE: Very detailed information, intended only for development. You might keep trace messages for a short period of time after deployment on production environment, but treat these log statements as temporary, that should or might be turned-off eventually. The distinction between DEBUG and TRACE is the most difficult, but if you put logging statement and remove it after the feature has been developed and tested, it should probably be on TRACE level.
Concludo dicendo che piu’ di una volta mi e capitato di constatare che l’analisi di log ben scritti puo’ davvero fare la differenza in termini di tempo impiegato per riprodurre, capire e risolvere un problema.
Se poi i log per Android sono colorati, esaminarli e’ ancora piu’ facile! 😉