2

It seems like abit of overkill to allocate a different level just for a warning as opposed to error. If a value is wrong its wrongm its ok its not. Personally i tink these sort of fuzzy decisions make code difficult to understand because one know is not sure what consititutes acceptable valid input. If you do not accept crap and throw exceptions then hyour code will probably be the better for it, removing the need for warning altogether.

There are many other levels that get more logging that are probably more deserving of their own level - stuff like "config". However in the end it seems that most frameworks have settled on error, warning, info, debug and trace with variations thereof.

So how did warning survive and other levels did not ?

mP.
  • 18,002
  • 10
  • 71
  • 105
  • See http://stackoverflow.com/questions/2031163/when-to-use-log-level-warn-vs-error – Raedwald Feb 02 '11 at 13:03
  • @Raedwald that answerhas no thought it only describes the api, it makes no distinction about warning. Most methods only have 2 results, success or some exceptional outcome(ERROR). You would print the success or result as a INFO, any logging about calculations would be DEBUG. There is no need for warning, just like you dont throw Warnings, only Exceptions. – mP. Feb 03 '11 at 03:04
  • See also http://stackoverflow.com/questions/7839565/logging-levels-logback-rule-of-thumb-to-assign-log-levels – Raedwald Nov 28 '14 at 14:39
  • imo `Warn` -> something wasn't right and the user may not get what they wanted, but nothing broke and they didn't see an error page. `Error` -> stuff broke the user saw an error page. – Don Cheadle Nov 07 '16 at 21:02

4 Answers4

7

For the software I work on, I use the following distinctions.

  • error: the program is unable to perform the operation it has been requested to do. The program is required to output an error message if it can not do what it was requested to do.
  • warning: the program has detected something odd, which does not prevent it doing what it has been requested to do. The program may, but is not required, to output a warning message for odd situations.

It seems that others do likewise.

For example, imagine a configuration file that contains a list of locations that the program is to examine, and that list may be empty but is practically never empty.

  • The program would report an error message if the configuration file had the incorrect format, because it could not then work out what you want it to do and therefore can not do what you want.
  • It might report a warning if the configuration file listed no locations, because although it can correctly examine no locations in that case (that is, do nothing useful), it is likely that the user in fact incorrectly configured the system.
Community
  • 1
  • 1
Raedwald
  • 46,613
  • 43
  • 151
  • 237
1

I've used warnings for:

  1. Multiple failed login attempts from the same client. Not an error, and the login system can handle it, but sometimes one wants to be aware of the attempts. (Maybe an attack is happening, maybe a client needs assistance, etc.)
  2. Input data that isn't technically dangerous but may require manual oversight (user submitted possible foul language on a kid-friendly website, etc.)
  3. A process is taking longer than expected. Not errored out yet, but the support team wants to be aware of it.
David
  • 208,112
  • 36
  • 198
  • 279
  • Sounds like all the items you describe are "info" about some process. So why the diff ? – mP. Feb 02 '11 at 12:36
  • @mP: Depends on the requirements of the business. For the first one, any failed login was an info level event. Multiple in a row was to be escalated to a warning. Similar for the third one. The support team wanted it logged when it ran (info), notify them when it ran long (warn), report a problem when it ran longer than a configured window of time (error), report an outage when it failed to run (fatal/exception/etc.). Many times it just comes down to what the business wants reported at what severity. – David Feb 02 '11 at 12:40
  • You could still solve the problem by having different categories mapped to different appenders. Different problems log different messages to different categories. – mP. Feb 03 '11 at 02:58
1

The different log levels are useful because a developer wants to achieve different things at different times, i.e. find the cause of a critical/fatal bug (ERROR), or maintain the program and make sure it is doing what was intended (WARN).

ERROR means the program/subroutine cannot continue at all, and this probably represents a critical bug that needs to be fixed before the user can continue with their task.

WARN means the developer did not expect the program to do that, but the program may still satisfy the user requirements. The developer should periodically check the log for WARNs to decide whether or not a change is required (they may indicate a problem will develop in the future). There should ideally be no WARNs being triggered - they are a call to action for the developer to change something.

Will Sheppard
  • 3,272
  • 2
  • 31
  • 41
  • There are many other types of messages that could be added to a logging system besides D, I, W and E. Shouldnt >Warn< be a part of the message rather than the level ? If y ou have Warn as a level why not Config etc. – mP. Apr 07 '11 at 05:07
  • What would the config level be used for? – Will Sheppard Apr 07 '11 at 15:13
  • Configuration releated messages. Many app servers during startup/deployment etc log stuff to their logger under a "" level, eg WS,WLS etc. – mP. Apr 11 '11 at 03:32
0

I use the WARN level when the input/data is valid and acceptable, but might not be appropriate to the current application state, so that if I'll have to check the log regarding an issue, I'll be aware of a potential problem with the data.

Miki Watts
  • 1,746
  • 1
  • 17
  • 27
  • If the data is wrong its wrong, shouldnt that be an error. Let the logging category be the filter and log "errors" like bad data to that logger. If you want to insepect messages about bad input filter on that logger. – mP. Feb 02 '11 at 12:39
  • @mP: but what does "wrong" mean? The program does not have common sense, general knowledge or background information. It can not understand that the computer operator is doing a special program run using an unusual configuration becuase they are preparing for an upgrade. The operator has not made an *error* in that circumstance, and then programmer should not presume to label such usage as an error. – Raedwald Feb 02 '11 at 12:47
  • I didn't say that the data was wrong. For example, I'm developing a POS application, which has to go out to a credit card provider, and get back the issuer credit company and clearing credit company ids. Sometimes, the provider returns 0 instead of the correct ids. It's not an error, since the ids are used in reports only, but it's suspect that something might have gone wrong. – Miki Watts Feb 02 '11 at 13:53
  • @Miki which is why one should log an INFO with provider failed trying again type of message. If after too many tries it still fails and ytiou give up then you log an ERROR. – mP. Feb 03 '11 at 02:59
  • @Raedwald, thats why you as the developer setup categories to describe different types of problems, and log your message to the appropriate target when something goes wrong. Wrong is something that is not expected and harmful for the action being attempted. Commentary along the way are INFO, printing variables etc is DEBUG. – mP. Feb 03 '11 at 03:01
  • @mP no, wrong is not "something unexpected". This is not an issue of programming. It is an issue of English usage. Imagine I'm a regular in a bar, where I usually order a pint of beer. But one day I order a glass of wine. If would be strange for the barmman to say "you are wrong to order a glass of wine". – Raedwald Feb 03 '11 at 12:44
  • @mP again, the operation did not fail, the credit card charge went through just fine, just some of the secondary, non critical information came back as something which might be suspect. – Miki Watts Feb 05 '11 at 18:38
  • @Miki Fine or suspect or whatever, its all immaterial. Its really important use a different/second logger (set perhaps to info) and log it as an info. All your other info will go to the first logger. Your CreditCardProcessor now has two loggers. – mP. Feb 05 '11 at 22:02