cflog (writeLog in CFScript) writes a message to a log file, separate from anything the user ever sees on screen. It's how every earlier lesson's advice to "log the real detail, show the user something generic" actually gets carried out.
Learning Objectives
After completing this lesson, you'll be able to:
- Write a log entry with cflog/writeLog, using the right severity type and destination.
- Log real diagnostic detail from inside a cfcatch block.
- Recognize where Lucee's log tag genuinely differs from Adobe's cflog.
How cflog Fits In
Exception Caught (cfcatch / onError)
cflog / writeLog
Log File
Reviewed Later, Separately From the User
A Basic Log Entry
<cflog file="myAppLog" text="Whatever you want to log." type="information">
writeLog(text = "Whatever you want to log.", type = "information", file = "myAppLog");
cflog's Attributes (Adobe)
| Attribute | Meaning |
|---|---|
| text | The message to log (required) |
| log | Destination when file isn't specified: Application or Scheduler; defaults to the standard log |
| file | A custom log filename (just the name, no path); created automatically if it doesn't exist |
| type | Severity: information, warning, error, or fatal |
| application | Whether to include the application name (from cfapplication or Application.cfc) in the entry |
Each entry is written comma-delimited: the log entry type, thread ID, date/time, application name, and the message text.
A Real Example: Logging Full Detail From a Catch Block
This is the pattern every earlier lesson in this module pointed toward: log the exception's real fields server-side, and show the user only a generic message.
<cftry>
<cfset chargePaymentMethod(customer, orderTotal)>
<cfcatch type="any">
<cflog
file="payment-errors"
type="error"
text="#cfcatch.type#: #cfcatch.message# | #cfcatch.detail#">
<cfoutput>Your payment could not be processed, please try again.</cfoutput>
</cfcatch>
</cftry>try {
chargePaymentMethod(customer, orderTotal);
} catch (any e) {
writeLog(
file = "payment-errors",
type = "error",
text = "#e.type#: #e.message# | #e.detail#"
);
writeOutput("Your payment could not be processed, please try again.");
}How Lucee's log Tag Genuinely Differs
| Aspect | Adobe cflog | Lucee log |
|---|---|---|
| Severity levels | information, warning, error, fatal (4 levels) | trace, debug, info, warn, error, fatal (6 levels); defaults to info (ERROR-only by default on Lucee 6.2+) |
| Custom destination | file — a plain filename in the default log directory | file is deprecated; log references a named log predefined in the Administrator or Application.cfc's this.logs, for a cached, reused file connection |
| Logging an exception object directly | Not supported — build the message string yourself from cfcatch's fields | An exception attribute accepts the exception object directly |
| Writing off the main thread | Not available | An async attribute writes the entry in a separate thread (requires file) |
Lucee 6.2+ only shows error and fatal messages by default, an information/warning-level cflog call that worked fine on Adobe ColdFusion can silently produce nothing on Lucee unless the log level is configured explicitly.
A Lucee-Specific Example: Logging an Exception Directly
try {
processPaymentBatch(batch);
} catch (any e) {
log(exception = e, log = "payment-errors");
}Passing the caught exception straight to the exception attribute skips manually assembling a message string from its individual fields, an option Adobe's cflog doesn't have.
Common Beginner Mistakes
Assuming an information-level cflog call always shows up in the log
On Lucee 6.2+, only error and fatal messages appear by default. A lower-severity entry that worked on Adobe ColdFusion can silently vanish on Lucee unless the log level is configured to include it.
Passing a path in the file attribute
file only accepts a plain filename, ColdFusion writes it into the default log directory itself, it can't be redirected to an arbitrary path.
Logging a raw exception object as the text attribute on Adobe ColdFusion
Adobe's cflog has no exception attribute, the message has to be built from cfcatch's individual fields (message, detail, type) as a string. That shortcut is Lucee-specific.
Using a generic type like information for something that's actually an error
Matching the real severity, error or fatal for genuine failures, keeps a log usable for filtering later; everything logged as information makes real problems harder to find.
Best Practices
- Log the full exception detail (message, detail, type) from inside a catch block or onError, not just a generic string.
- Match the type/severity to what actually happened, reserve error and fatal for real failures.
- On Lucee, prefer a predefined log (log attribute, configured via this.logs) over the deprecated file attribute for a cached, reused file connection.
- Confirm the effective log level in production before relying on a lower-severity entry actually appearing, especially on Lucee 6.2+.
Interview Questions
What are cflog's four severity types on Adobe ColdFusion?
information, warning, error, and fatal.
Why might a cflog call that works on Adobe ColdFusion produce nothing on Lucee 6.2+?
Lucee 6.2+ defaults to showing only error and fatal messages, an information or warning-level entry needs the log level explicitly configured to appear.
What's the difference between cflog's file attribute and Lucee's log attribute?
file is a plain filename that Lucee now considers deprecated because its file connection isn't cached. log instead references a named log predefined in the Administrator or Application.cfc's this.logs, for better performance.
How would you log the details of a caught exception without exposing them to the user?
Write the exception's message, detail, and type to a log file with cflog/writeLog inside the catch block (or onError), while showing the user only a generic, non-technical message.
Summary
In this lesson, you wrote log entries with cflog/writeLog, logged real diagnostic detail from inside a catch block instead of exposing it to the user, and covered where Lucee's log tag genuinely differs from Adobe's, its six severity levels, the deprecated file attribute in favor of a predefined log, and logging an exception object directly.
What's Next?
The next lesson zooms out from the tag itself to how logging fits into a broader error-handling workflow, deciding what's worth logging and at what severity, together with everything covered earlier in this module.