| Severity | Method | Appropriate for |
|---|---|---|
| MAX | mark() |
a) Temporary only, while developing; never on master or in production |
| 5 | fatal() |
a) Every uncaught exception |
| 4 | error() |
a) Every throw, swallowed or not |
| 3 | warn() |
a) Any debug or info that contains bad news |
| 2 | info() |
a) Side effects after success; b) task progress; see warn |
| 1 | trace() |
a) Upon entry into every routine, sig & values |
| MIN | debug() |
a) Every calculation of note; b) "attempting X..."; see warn |
- Log statements must be present in the application before the bad things happens that you wish to study. You can't retroactively create logging data by adding log statements after the fact.
- Do not bother with English style-guide stuff: sentence case, grammar, etc. Make it accurate, precise, brief, and clear, and be done.
- Never add noisy nonsense (e.g.
!!!!!,>>>> HERE <<<<, etc.) to a log statement for the purpose of making it stand out. - When dumping a variable, do it in a way that will reveal its real datatype as well as its value. In JS, that means using
JSON.stringify. - It is better (because clearer) to log that you are about to try a risky operation than to log that you have just completed the risky operation.