[housecor]

Logging has its place, but I'd argue it's far more important that great programmers write code that fails fast. In his example, he didn't have instrumentation in production to determine why a module was returning null. If null isn't an expected return value, then an exception should be thrown to avoid the system moving forward in a crippled and unpredictable state. A well tested system that stops processing and fails fast with a descriptive exception greatly reduces the need for time-consuming and resource depleting logging systems.

[henrik_w]

Thanks for a good comment. Failing fast is great. In this case, since null was returned, the whole call failed gracefully (returning an error code to the calling party instead of simply throwing an exception).

The key point though: however the problem is detected, you need to have enough information to help you answer the question "Why did it fail?". You can add information in an exception, or in traces/logs, as long as you can tell why it happened, not just that it happened.

[gbog]

Yes but no, in many cases you do not want to fail fast and loudly. If a corner case in a minor module crashes all the pages of your app, you better fail silently, and log.

[henrik_w]

Or at least fail gracefully, by e.g. returning an error code to the caller. Simply crashing isn't always the best choice.