tracker issue : CF-3788414

select a category, or use search below
(searches all categories and all time range)

writeLog(), throw(), writeDump() not implemented as fucntions correctly

| View in Tracker

Status/Resolution/Reason: Closed/Won't Fix/

Reporter/Name(from Bugbase): Adam Cameron / Adam Cameron (Adam Cameron)

Created: 07/14/2014

Components: Language

Versions: 11.0

Failure Type:

Found In Build/Fixed In Build: CF11_Final /

Priority/Frequency: Major / Some users will encounter

Locale/System: ALL / Platforms All

Vote Count: 7


This should work:
x = throw(type="MissingArgumentException", message="The correct exception was thrown");

However it errors:

Parameter validation error for the THROW function.
A built-in ColdFusion function cannot accept an assignment statement as a parameter, although it can accept expressions. For example, THROW(d=a*b) is not acceptable.

That error message is bogus.

Same / similar with the other two I mentioned. It seems to be related to the functions which take name/value pairs for arguments. The parser doesn't seem to "understand" them in some (completely valid) situations.


----------------------------- Additional Watson Details -----------------------------

Watson Bug ID:	3788414

External Customer Info:
External Company:  
External Customer Name: Adam Cameron.
External Customer Email:  
External Test Config: My Hardware and Environment details:



+1 ......................
Vote by External U.
11632 | November 16, 2014 02:27:41 AM GMT
please fix this...........
Vote by External U.
11633 | December 22, 2014 03:51:17 PM GMT
++1 This should have been fixed ASAP. Correct implementation of these functions is critical to developers.
Vote by External U.
11634 | December 22, 2014 04:08:33 PM GMT
ColdFusion was looking at the following text:<p>text</p> in the context of writeLog(file="errorLogging" text writeLog should have the parameter of text available.
Vote by External U.
11635 | March 24, 2015 09:32:09 AM GMT
Hey Tim, from your code snippet: you're missing a comma between your arguments there. That's why yer getting the error.
Comment by External U.
11624 | March 25, 2015 03:42:24 AM GMT
It doesn't make sense for functions like writeDump, writeLog or throw to return anything and hence they will not be supported in assignment or ternary operators. For validation we checked other languages too but didn't found any strong example. So we will not fix this. The behavior is as expected.
Comment by Milan C.
11625 | October 27, 2015 10:45:31 PM GMT
No, Milan. It doesn't make sense for functions like [anything] to not *behave* as functions. A function can be used in an expression. That is part of what being a function is. This is not about return values, it's about uniformity of the language implementation, and that functions are supposed to be able to be used in expressions. This is pretty much by definition. Even if a function doesn't return a value (so it's a void function), then it should be able to be used in any expression which expects a null value. It's not for you to second guess how we might use these, and whilst your imagination might not extend to how these might be used in expressions doesn't mean they can't be. If you implement a function, it should behave like a function. The end. You are just making CFML that tiny bit more rubbish by taking this approach you have As for usage? You clearly didn't even read the reference material provided with the ticket, as I provided a use case for you. expectedValue = someAction ? someResult : throw("it messed up"); // or equally legitimately writing a log entry, with writeLog() returning null. This is not an every day occurrence, but it's legit and demonstrates it should not be up to *you* how the language users might use the language. But let's also look at other languages. This is completely fine (if contrived) in PHP: $result = rand(0,1) ? printf("yay") : error_log("boo", 3, "C:\\temp\\test.log"); where printf() is the equivalent of writeOutput(), and error_log() the equivalent of writeLog(). In JS, console.log() is a function which can be used in an expression ("throw" is a statement, so cannot); in Ruby throwing an exception is an expression. I could really easily keep demonstrating this to you across other languages if you like, but I think it's self-evident that *in other languages* functions... have been implemented properly. All functions. You've just done this wrong,Milan, because you didn't think it through.
Comment by External U.
11626 | October 28, 2015 03:04:00 AM GMT
+1 ......................
Vote by External U.
11636 | October 28, 2015 11:18:12 AM GMT
@Adam, you might be right, not arguing on that, but changing these functions behavior now adds a high risk of breaking backward compatibility.
Comment by Milan C.
11627 | November 02, 2015 01:08:20 PM GMT
Go on then... do tell... what is an example of a potential backwards compat issue you perceive here. An actual *real world* example. You can't just say "backwards compat" and then not demonstrate how this is the case.
Comment by External U.
11628 | November 03, 2015 03:30:48 AM GMT
I'd be curious to see what real backward compatibility issues are at play here.
Comment by External U.
11629 | November 03, 2015 09:25:01 AM GMT
+1. . . . . . . . . . . . . . .
Vote by External U.
11637 | November 03, 2015 09:26:25 AM GMT
Need consistency. Please explain in 25 characters or more how this bug impacts productivity and why you are adding a vote.
Vote by External U.
11638 | November 03, 2015 10:14:31 AM GMT
Hi Adobe, Copying my comment from Slack: -------------------------------------------- There are definitely inconsistencies. foo = writeOutput("foo");//displays "foo" foo = writeDump("foo");//displays "coldfusion.compiler.MethodNotFoundException: Method writeDump with 1 arguments is not in class coldfusion.runtime.CFPage." writeOutput("bar")//A script statement must end with ";" writeDump("bar")//Displays "bar" How about treating all built-in functions the same? Is that possible? Thanks!, -Aaron
Comment by External U.
11630 | November 03, 2015 02:24:42 PM GMT
Come on the Adobe, enough of this "oh, this isn't going the way we would like it to, so we're just gonna ignore it". So... Milan... pls detail the backwards compat problems you have identified. Real world ones, not theoretical ones.
Comment by External U.
11631 | February 08, 2016 03:09:45 AM GMT