In our app, we are handling all uncaught errors in the Application.cfconError() method. Then, we take those errors and write them to the system output stream using structured logging (ie, as JSON payloads). It seems, however, even though we “handled” the error, ColdFusion is still logging the raw error to the output stream (where our log aggregation is picking it up and aggregating it).
So, for all errors that get handled at the Application.cfc level, they get logged twice: once structured, once unstructured.
Question: Is there any way for me to disable native logging of error that are handled by onError()?
Hey Ben, are you really asking about Lucee or CF? And about the “structured” log entry, are you writing it with cfml (writelog/cflog)?
I ask because from my experience with cf at least, an error handler DOES override/prevent acf itself logging the error. But by the same token, acf has long had the characteristic that any lines logged by writelog/cflog are written to not only the named file destination but ALSO to the console (or coldfusion-out.log, when running it as a service). And I’d not found or heard of a way to stop that, though I suspect it can be done.
Sorry if you really meant Lucee here. I realize of course this is the lucee Dev forum (and that most say acf here when they mean to cf) , but since you said “cf” and you do sometimes speak of acf specifically in your blog posts, I wondered if maybe you just defaulted to asking about it here rather than the Adobe cf forums.
If either you really mean Lucee or you are writing your structured log lines using Java or otherwise, I’ll step back and let those more experienced with Lucee step in.
I’ve tried repeating this and I think it might be a bug. If you have the “Appender” set to “resource” (e.g. file) then it doesn’t log it if handled by onError but if you have the “Appender” set to “console” it does log it even when handled by onError. Surely the appender used should have no bearing on whether or not it logs it when there is handling.
Ah, very interesting. I can confirm this on my end as well. Though, I realized it was the Application log, not the Exception log, that I had to change to be a “resource”.
As a temporary fix, I might be able to just setup a symbol-link to /dev/stderr. Though, since the resource configuration in the Admin points to a directory, not a file, I am not sure if the file name will be predictable enough.