kashifrazzaqui/gist:f2c249a1033f4cdb47239dbb6a18889b

## gistfile1.txt
Logging is used for 3 primary goals
* debugging
* tracing - understanding execution flow of the program in real life
* checking inputs

There are better tools available for all these three tasks for most usecases
Lets see each case.

Debugging - When a bug is reported the first order of business is to write a test case that fails and this failure clearly indicates that the bug is present - the code is then modified till this test passes (and no other ones fail) - no need for logging

Tracing - Code flow, use a profiler. They all come with method and module hooks and allow you to run them all the time or on certain conditions. They give nice graphs and reports - almost always better than logging

Checking inputs - are they what we expect them to be. Encoding, form data etc are good examples. The best tool for this is asserts, when its possible to know what is not acceptable - but this is not always the case. The second tool that covers this is unit testing, to be precise, parameterized unit tests and fuzz testing. Again, no need for logging

Yet, in real life things don't always work out so neatly, so in the exceptional case we should really use logging. Unfortunately when all you have is a hammer(logging) - then everything appears like a nail
	Logging is used for 3 primary goals
	* debugging
	* tracing - understanding execution flow of the program in real life
	* checking inputs

	There are better tools available for all these three tasks for most usecases
	Lets see each case.

	Debugging - When a bug is reported the first order of business is to write a test case that fails and this failure clearly indicates that the bug is present - the code is then modified till this test passes (and no other ones fail) - no need for logging

	Tracing - Code flow, use a profiler. They all come with method and module hooks and allow you to run them all the time or on certain conditions. They give nice graphs and reports - almost always better than logging

	Checking inputs - are they what we expect them to be. Encoding, form data etc are good examples. The best tool for this is asserts, when its possible to know what is not acceptable - but this is not always the case. The second tool that covers this is unit testing, to be precise, parameterized unit tests and fuzz testing. Again, no need for logging

	Yet, in real life things don't always work out so neatly, so in the exceptional case we should really use logging. Unfortunately when all you have is a hammer(logging) - then everything appears like a nail