Logging

The previous lesson covered cflog/writeLog itself, its attributes and severity types. This lesson is about putting it to work: what's actually worth logging, at what severity, and how it ties together with cfcatch and onError from earlier in this module.

Learning Objectives

After completing this lesson, you'll be able to:

Decide what's genuinely worth logging, and at what severity.
Combine cfcatch, onError, and cflog into one coherent error-handling flow.
Avoid the common failure modes: over-logging, under-logging, and inconsistent severity.

How the Whole Module Fits Together

cftry / cfcatch Catches It

Escaped Everything? onError Catches It

cflog Records the Real Detail

User Sees Something Generic and Safe

NOTE

Every mechanism from this module has a specific job: cftry/cfcatch handle what's expected, onError catches whatever escapes that, and cflog is how either one leaves a record behind for someone to actually review later.

A Real Example: Combining onError and cflog

Application.cfc — CFScript

function onError(exception, eventName) {
    writeLog(
        file = "application-errors",
        type = "error",
        text = "[#eventName#] #exception.type#: #exception.message# | #exception.detail#"
    );

    cfheader(statuscode = 500, statustext = "Internal Server Error");
    writeOutput("<h1>Something went wrong</h1><p>Please try again shortly.</p>");
}

NOTE

This is the same onError from the previous lesson, now with the logging call filled in: the full exception, including which lifecycle event it happened during, goes to a dedicated log file, while the user still sees only a generic message.

Deciding What's Worth Logging

Anything that reaches onError, by definition it escaped every other handler and needs a record.
Caught exceptions in a cfcatch block where the failure is unexpected, not routine (a genuinely failed payment, not a normal validation rejection).
Enough context to actually act on later: the exception's type, message, and detail, not just "an error occurred."

Common Mistakes

Over-logging routine, expected outcomes

Logging every validation rejection or expected "not found" case at error severity buries genuine failures in noise, making the log far less useful for spotting what actually needs attention.

Under-logging: swallowing an exception with an empty or near-empty catch block

A catch block with no logging and no rethrow makes a real failure invisible, this was flagged as a mistake in the try/catch lesson too, and it applies just as much once cflog is available to fix it.

Using inconsistent severity for the same kind of failure across the codebase

If one part of the application logs a failed payment as error and another logs the same kind of failure as information, filtering the log by severity stops being reliable.

Logging sensitive data, like a full password or an unmasked payment card number

A log file is still a place that data sits in plain text, exception messages and detail should never be assumed safe to include raw sensitive input without checking first.

Best Practices

Reserve error and fatal for genuine failures, not for routine, expected outcomes.
Log consistently: the same kind of failure should get the same severity everywhere it happens.
Include enough detail (type, message, detail, and relevant context like an order or user ID) to actually act on later.
Never write raw sensitive data (passwords, full card numbers, tokens) into a log entry.

Interview Questions

How do cftry/cfcatch, onError, and cflog fit together in one coherent flow?

cftry/cfcatch handle exceptions that are expected, close to where they happen. Whatever escapes every one of those falls through to onError as the application-wide catch-all. Either mechanism uses cflog to leave a real record, while the user only ever sees a generic message.

Why is over-logging routine, expected outcomes a real problem?

It buries genuine failures in noise, at that point severity filtering stops being a useful signal for what actually needs attention.

What should never appear in a log entry, even during error handling?

Raw sensitive data, a full password, an unmasked payment card number, or a token, a log file is still plain text sitting on disk.

Summary

In this lesson, you combined cfcatch, onError, and cflog into one coherent error-handling flow, decided what's genuinely worth logging and at what severity, and covered the real failure modes: over-logging routine outcomes, under-logging by swallowing exceptions silently, inconsistent severity, and logging sensitive data.

What's Next?

The next lesson covers debugging: ColdFusion's built-in debugging output and the techniques for tracing a problem when a log entry alone isn't enough.