Published:
Warning: This blog entry was written two or more years ago. Therefore, it may contain broken links, out-dated or misleading content, or information that is just plain wrong. Please read on with caution.
So last week I got assigned a ticket to fix a bug in a part of our system I had not looked at before. Basically the error was the the user was trying to generate a png from one of our svg templates but nothing was happening.
Sure enough when I went to replicate the bug the tool would present me the option to generate the png and then display the output screen sans the image. What was really odd was that while no file was being generated there were no errors coming from cfexecute which calls the tool we use to create the image.
<cfexecute
name="{path to the executable file}"
arguments="{some other arguments} #sourcefilepath# #destinationfilepath#"
variable="returnedResults">
</cfexecute>
cfexecute ignores standard error
The reason it turns out for this is that cfexecute ignores anything sent to standard error by the called process. So while an error was being thrown in the converter tool, cfexecute was blithely ignoring it and continuing on as if everything was ok.
Getting error details out of cfexecute
To get around this limitation an attribute "errorvariable" was added (back in CF8) to the cfexecute tag to return any errors that may have been generated. Use as follows:
<cfexecute
name="{the command you want to run}"
arguments="{any arguments}"
variable="returnedResults"
errorVariable="returnedError">
</cfexecute>
<cfif len(returnedError)>
<cfthrow message="#returnedError#" />
</cfif>
Reader Comments
Tuesday, May 13, 2014 at 12:35:32 AM Coordinated Universal Time
Nice demonstration, though it's worth mentioning that things can get a bit more complicated from case to case, since some applications will also output their legitimate status messages to the error stream instead of the standard output (e.g., http://wkhtmltopdf.org/).