You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@velocity.apache.org by "Malcolm Edgar (JIRA)" <ji...@apache.org> on 2006/03/04 23:31:39 UTC
[jira] Created: (VELOCITY-435) ParseErrorException not thrown with
#macro parse error
ParseErrorException not thrown with #macro parse error
------------------------------------------------------
Key: VELOCITY-435
URL: http://issues.apache.org/jira/browse/VELOCITY-435
Project: Velocity
Type: Bug
Versions: 1.5
Environment: Windows XP, JDK 1.4.2_09
Reporter: Malcolm Edgar
I have just been reviewing the new error handlingin Velocity 1.5-dev.
One change I have observed it that an invalid macro call, passing 2
arguments instead of one will log an error message:
[Velocity] [error] VM #writeForm: error : too many arguments to macro.
Wanted 1 got 2
[Velocity] [error] VM error writeForm. Null AST
However it will not throw an ParseErrorException like it used to in
1.5-dev. Please see the example below for the earlier behaviour:
http://www.sunvolt.com/click-examples/exception.htm?actionLink=brokenBorderLink#
I prefer earlier approach, as the error is explicit. The new approach
logs an error message, but beyond that you would not have known that
an error occured. The #writeForm() call is not even rendered, as is
done with an invalid object reference.
regards Malcolm Edgar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
[jira] Resolved: (VELOCITY-435) ParseErrorException not thrown with
#macro parse error
Posted by "Will Glass-Husain (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/VELOCITY-435?page=all ]
Will Glass-Husain resolved VELOCITY-435.
----------------------------------------
Resolution: Fixed
Fix applied. Need to set property "velocimacro.arguments.strict" to true for the exception to be thrown. Thanks for the idea, Malcom!
> ParseErrorException not thrown with #macro parse error
> ------------------------------------------------------
>
> Key: VELOCITY-435
> URL: http://issues.apache.org/jira/browse/VELOCITY-435
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Affects Versions: 1.5
> Environment: Windows XP, JDK 1.4.2_09
> Reporter: Malcolm Edgar
> Assigned To: Will Glass-Husain
> Fix For: 1.5
>
> Attachments: macroargumenterror.patch
>
>
> I have just been reviewing the new error handlingin Velocity 1.5-dev.
> One change I have observed it that an invalid macro call, passing 2
> arguments instead of one will log an error message:
> [Velocity] [error] VM #writeForm: error : too many arguments to macro.
> Wanted 1 got 2
> [Velocity] [error] VM error writeForm. Null AST
> However it will not throw an ParseErrorException like it used to in
> 1.5-dev. Please see the example below for the earlier behaviour:
> http://www.sunvolt.com/click-examples/exception.htm?actionLink=brokenBorderLink#
> I prefer earlier approach, as the error is explicit. The new approach
> logs an error message, but beyond that you would not have known that
> an error occured. The #writeForm() call is not even rendered, as is
> done with an invalid object reference.
> regards Malcolm Edgar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
[jira] Commented: (VELOCITY-435) ParseErrorException not thrown
with #macro parse error
Posted by "Will Glass-Husain (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/VELOCITY-435?page=comments#action_12371089 ]
Will Glass-Husain commented on VELOCITY-435:
--------------------------------------------
Hi Malcolm,
Actually this is intentional. We now allow comments or spaces are parameter separators in macros.
WILL
> ParseErrorException not thrown with #macro parse error
> ------------------------------------------------------
>
> Key: VELOCITY-435
> URL: http://issues.apache.org/jira/browse/VELOCITY-435
> Project: Velocity
> Type: Bug
> Versions: 1.5
> Environment: Windows XP, JDK 1.4.2_09
> Reporter: Malcolm Edgar
> Fix For: 1.5
> Attachments: macroargumenterror.patch
>
> I have just been reviewing the new error handlingin Velocity 1.5-dev.
> One change I have observed it that an invalid macro call, passing 2
> arguments instead of one will log an error message:
> [Velocity] [error] VM #writeForm: error : too many arguments to macro.
> Wanted 1 got 2
> [Velocity] [error] VM error writeForm. Null AST
> However it will not throw an ParseErrorException like it used to in
> 1.5-dev. Please see the example below for the earlier behaviour:
> http://www.sunvolt.com/click-examples/exception.htm?actionLink=brokenBorderLink#
> I prefer earlier approach, as the error is explicit. The new approach
> logs an error message, but beyond that you would not have known that
> an error occured. The #writeForm() call is not even rendered, as is
> done with an invalid object reference.
> regards Malcolm Edgar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
[jira] Commented: (VELOCITY-435) ParseErrorException not thrown
with #macro parse error
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/VELOCITY-435?page=comments#action_12371026 ]
Malcolm Edgar commented on VELOCITY-435:
----------------------------------------
Hi Will,
I have run up your test case against Velocity 1.4.
I am afraid my error description was actually mis leading, the cause of the error was not a second argument:
#foo('test1' 'test2')
But adding a comma between the arguments. This causes a ParseErrorException in 1.4 and previous versions of 1.5-dev, but not in the latest 1.5-dev code.
#foo('test1,' 'test2')
regards Malcolm Edgar
> ParseErrorException not thrown with #macro parse error
> ------------------------------------------------------
>
> Key: VELOCITY-435
> URL: http://issues.apache.org/jira/browse/VELOCITY-435
> Project: Velocity
> Type: Bug
> Versions: 1.5
> Environment: Windows XP, JDK 1.4.2_09
> Reporter: Malcolm Edgar
> Fix For: 1.5
> Attachments: macroargumenterror.patch
>
> I have just been reviewing the new error handlingin Velocity 1.5-dev.
> One change I have observed it that an invalid macro call, passing 2
> arguments instead of one will log an error message:
> [Velocity] [error] VM #writeForm: error : too many arguments to macro.
> Wanted 1 got 2
> [Velocity] [error] VM error writeForm. Null AST
> However it will not throw an ParseErrorException like it used to in
> 1.5-dev. Please see the example below for the earlier behaviour:
> http://www.sunvolt.com/click-examples/exception.htm?actionLink=brokenBorderLink#
> I prefer earlier approach, as the error is explicit. The new approach
> logs an error message, but beyond that you would not have known that
> an error occured. The #writeForm() call is not even rendered, as is
> done with an invalid object reference.
> regards Malcolm Edgar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
[jira] Updated: (VELOCITY-435) ParseErrorException not thrown with
#macro parse error
Posted by "Henning Schmiedehausen (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/VELOCITY-435?page=all ]
Henning Schmiedehausen updated VELOCITY-435:
--------------------------------------------
Component/s: Engine
> ParseErrorException not thrown with #macro parse error
> ------------------------------------------------------
>
> Key: VELOCITY-435
> URL: http://issues.apache.org/jira/browse/VELOCITY-435
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Affects Versions: 1.5
> Environment: Windows XP, JDK 1.4.2_09
> Reporter: Malcolm Edgar
> Fix For: 1.5
>
> Attachments: macroargumenterror.patch
>
>
> I have just been reviewing the new error handlingin Velocity 1.5-dev.
> One change I have observed it that an invalid macro call, passing 2
> arguments instead of one will log an error message:
> [Velocity] [error] VM #writeForm: error : too many arguments to macro.
> Wanted 1 got 2
> [Velocity] [error] VM error writeForm. Null AST
> However it will not throw an ParseErrorException like it used to in
> 1.5-dev. Please see the example below for the earlier behaviour:
> http://www.sunvolt.com/click-examples/exception.htm?actionLink=brokenBorderLink#
> I prefer earlier approach, as the error is explicit. The new approach
> logs an error message, but beyond that you would not have known that
> an error occured. The #writeForm() call is not even rendered, as is
> done with an invalid object reference.
> regards Malcolm Edgar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
[jira] Commented: (VELOCITY-435) ParseErrorException not thrown
with #macro parse error
Posted by "Malcolm Edgar (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/VELOCITY-435?page=comments#action_12371027 ]
Malcolm Edgar commented on VELOCITY-435:
----------------------------------------
The strict mode parameter is an excellent idea.
regards Malcolm
> ParseErrorException not thrown with #macro parse error
> ------------------------------------------------------
>
> Key: VELOCITY-435
> URL: http://issues.apache.org/jira/browse/VELOCITY-435
> Project: Velocity
> Type: Bug
> Versions: 1.5
> Environment: Windows XP, JDK 1.4.2_09
> Reporter: Malcolm Edgar
> Fix For: 1.5
> Attachments: macroargumenterror.patch
>
> I have just been reviewing the new error handlingin Velocity 1.5-dev.
> One change I have observed it that an invalid macro call, passing 2
> arguments instead of one will log an error message:
> [Velocity] [error] VM #writeForm: error : too many arguments to macro.
> Wanted 1 got 2
> [Velocity] [error] VM error writeForm. Null AST
> However it will not throw an ParseErrorException like it used to in
> 1.5-dev. Please see the example below for the earlier behaviour:
> http://www.sunvolt.com/click-examples/exception.htm?actionLink=brokenBorderLink#
> I prefer earlier approach, as the error is explicit. The new approach
> logs an error message, but beyond that you would not have known that
> an error occured. The #writeForm() call is not even rendered, as is
> done with an invalid object reference.
> regards Malcolm Edgar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
[jira] Commented: (VELOCITY-435) ParseErrorException not thrown
with #macro parse error
Posted by "Will Glass-Husain (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/VELOCITY-435?page=comments#action_12370991 ]
Will Glass-Husain commented on VELOCITY-435:
--------------------------------------------
Just to clarify my findings, these errors cause exceptions to be thrown
* errors in macro body
* syntax errors in macro arguments, e.g.
#foo(abc)
But calling macros with an invalid number of arguments does not thrown an exception, only logs an error
#foo ("abc" "def")
when #foo expects 1 argument
The behavior appears to be the same in 1.4 and the latest source control head.
> ParseErrorException not thrown with #macro parse error
> ------------------------------------------------------
>
> Key: VELOCITY-435
> URL: http://issues.apache.org/jira/browse/VELOCITY-435
> Project: Velocity
> Type: Bug
> Versions: 1.5
> Environment: Windows XP, JDK 1.4.2_09
> Reporter: Malcolm Edgar
> Fix For: 1.5
>
> I have just been reviewing the new error handlingin Velocity 1.5-dev.
> One change I have observed it that an invalid macro call, passing 2
> arguments instead of one will log an error message:
> [Velocity] [error] VM #writeForm: error : too many arguments to macro.
> Wanted 1 got 2
> [Velocity] [error] VM error writeForm. Null AST
> However it will not throw an ParseErrorException like it used to in
> 1.5-dev. Please see the example below for the earlier behaviour:
> http://www.sunvolt.com/click-examples/exception.htm?actionLink=brokenBorderLink#
> I prefer earlier approach, as the error is explicit. The new approach
> logs an error message, but beyond that you would not have known that
> an error occured. The #writeForm() call is not even rendered, as is
> done with an invalid object reference.
> regards Malcolm Edgar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
[jira] Updated: (VELOCITY-435) ParseErrorException not thrown with
#macro parse error
Posted by "Will Glass-Husain (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/VELOCITY-435?page=all ]
Will Glass-Husain updated VELOCITY-435:
---------------------------------------
Fix Version: 1.5
I agree. Let's make this work as Malcolm describes.
> ParseErrorException not thrown with #macro parse error
> ------------------------------------------------------
>
> Key: VELOCITY-435
> URL: http://issues.apache.org/jira/browse/VELOCITY-435
> Project: Velocity
> Type: Bug
> Versions: 1.5
> Environment: Windows XP, JDK 1.4.2_09
> Reporter: Malcolm Edgar
> Fix For: 1.5
>
> I have just been reviewing the new error handlingin Velocity 1.5-dev.
> One change I have observed it that an invalid macro call, passing 2
> arguments instead of one will log an error message:
> [Velocity] [error] VM #writeForm: error : too many arguments to macro.
> Wanted 1 got 2
> [Velocity] [error] VM error writeForm. Null AST
> However it will not throw an ParseErrorException like it used to in
> 1.5-dev. Please see the example below for the earlier behaviour:
> http://www.sunvolt.com/click-examples/exception.htm?actionLink=brokenBorderLink#
> I prefer earlier approach, as the error is explicit. The new approach
> logs an error message, but beyond that you would not have known that
> an error occured. The #writeForm() call is not even rendered, as is
> done with an invalid object reference.
> regards Malcolm Edgar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
[jira] Closed: (VELOCITY-435) ParseErrorException not thrown with
#macro parse error
Posted by "Henning Schmiedehausen (JIRA)" <de...@velocity.apache.org>.
[ https://issues.apache.org/jira/browse/VELOCITY-435?page=com.atlassian.jira.plugin.system.issuetabpanels:all-tabpanel ]
Henning Schmiedehausen closed VELOCITY-435.
-------------------------------------------
> ParseErrorException not thrown with #macro parse error
> ------------------------------------------------------
>
> Key: VELOCITY-435
> URL: https://issues.apache.org/jira/browse/VELOCITY-435
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Affects Versions: 1.5
> Environment: Windows XP, JDK 1.4.2_09
> Reporter: Malcolm Edgar
> Assigned To: Will Glass-Husain
> Fix For: 1.5
>
> Attachments: macroargumenterror.patch
>
>
> I have just been reviewing the new error handlingin Velocity 1.5-dev.
> One change I have observed it that an invalid macro call, passing 2
> arguments instead of one will log an error message:
> [Velocity] [error] VM #writeForm: error : too many arguments to macro.
> Wanted 1 got 2
> [Velocity] [error] VM error writeForm. Null AST
> However it will not throw an ParseErrorException like it used to in
> 1.5-dev. Please see the example below for the earlier behaviour:
> http://www.sunvolt.com/click-examples/exception.htm?actionLink=brokenBorderLink#
> I prefer earlier approach, as the error is explicit. The new approach
> logs an error message, but beyond that you would not have known that
> an error occured. The #writeForm() call is not even rendered, as is
> done with an invalid object reference.
> regards Malcolm Edgar
--
This message is automatically generated by JIRA.
-
You can reply to this email to add a comment to the issue online.
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@velocity.apache.org
For additional commands, e-mail: dev-help@velocity.apache.org
[jira] Updated: (VELOCITY-435) ParseErrorException not thrown with
#macro parse error
Posted by "Will Glass-Husain (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/VELOCITY-435?page=all ]
Will Glass-Husain updated VELOCITY-435:
---------------------------------------
Attachment: macroargumenterror.patch
Attached file - throws an argument for invalid macro argument count
> ParseErrorException not thrown with #macro parse error
> ------------------------------------------------------
>
> Key: VELOCITY-435
> URL: http://issues.apache.org/jira/browse/VELOCITY-435
> Project: Velocity
> Type: Bug
> Versions: 1.5
> Environment: Windows XP, JDK 1.4.2_09
> Reporter: Malcolm Edgar
> Fix For: 1.5
> Attachments: macroargumenterror.patch
>
> I have just been reviewing the new error handlingin Velocity 1.5-dev.
> One change I have observed it that an invalid macro call, passing 2
> arguments instead of one will log an error message:
> [Velocity] [error] VM #writeForm: error : too many arguments to macro.
> Wanted 1 got 2
> [Velocity] [error] VM error writeForm. Null AST
> However it will not throw an ParseErrorException like it used to in
> 1.5-dev. Please see the example below for the earlier behaviour:
> http://www.sunvolt.com/click-examples/exception.htm?actionLink=brokenBorderLink#
> I prefer earlier approach, as the error is explicit. The new approach
> logs an error message, but beyond that you would not have known that
> an error occured. The #writeForm() call is not even rendered, as is
> done with an invalid object reference.
> regards Malcolm Edgar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
[jira] Commented: (VELOCITY-435) ParseErrorException not thrown
with #macro parse error
Posted by "Will Glass-Husain (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/VELOCITY-435?page=comments#action_12370990 ]
Will Glass-Husain commented on VELOCITY-435:
--------------------------------------------
Hi,
Spent some time working on this, even coded a solution. When I ran "ant test" though one of the Anakia tests failed due to an invalid macro call.
The problem is that there are likely thousands of Velocity templates out there with a macro argument problem. If we put this error check in 1.5, then all those templates will suddenly fail.
I do think that throwing an error here would be very appropriate. Maybe we need to add a "strict mode" property that will throw errors for invalid macro calls and invalid references.
Comments?
> ParseErrorException not thrown with #macro parse error
> ------------------------------------------------------
>
> Key: VELOCITY-435
> URL: http://issues.apache.org/jira/browse/VELOCITY-435
> Project: Velocity
> Type: Bug
> Versions: 1.5
> Environment: Windows XP, JDK 1.4.2_09
> Reporter: Malcolm Edgar
> Fix For: 1.5
>
> I have just been reviewing the new error handlingin Velocity 1.5-dev.
> One change I have observed it that an invalid macro call, passing 2
> arguments instead of one will log an error message:
> [Velocity] [error] VM #writeForm: error : too many arguments to macro.
> Wanted 1 got 2
> [Velocity] [error] VM error writeForm. Null AST
> However it will not throw an ParseErrorException like it used to in
> 1.5-dev. Please see the example below for the earlier behaviour:
> http://www.sunvolt.com/click-examples/exception.htm?actionLink=brokenBorderLink#
> I prefer earlier approach, as the error is explicit. The new approach
> logs an error message, but beyond that you would not have known that
> an error occured. The #writeForm() call is not even rendered, as is
> done with an invalid object reference.
> regards Malcolm Edgar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators:
http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see:
http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org
[jira] Assigned: (VELOCITY-435) ParseErrorException not thrown with
#macro parse error
Posted by "Will Glass-Husain (JIRA)" <ji...@apache.org>.
[ http://issues.apache.org/jira/browse/VELOCITY-435?page=all ]
Will Glass-Husain reassigned VELOCITY-435:
------------------------------------------
Assignee: Will Glass-Husain
> ParseErrorException not thrown with #macro parse error
> ------------------------------------------------------
>
> Key: VELOCITY-435
> URL: http://issues.apache.org/jira/browse/VELOCITY-435
> Project: Velocity
> Issue Type: Bug
> Components: Engine
> Affects Versions: 1.5
> Environment: Windows XP, JDK 1.4.2_09
> Reporter: Malcolm Edgar
> Assigned To: Will Glass-Husain
> Fix For: 1.5
>
> Attachments: macroargumenterror.patch
>
>
> I have just been reviewing the new error handlingin Velocity 1.5-dev.
> One change I have observed it that an invalid macro call, passing 2
> arguments instead of one will log an error message:
> [Velocity] [error] VM #writeForm: error : too many arguments to macro.
> Wanted 1 got 2
> [Velocity] [error] VM error writeForm. Null AST
> However it will not throw an ParseErrorException like it used to in
> 1.5-dev. Please see the example below for the earlier behaviour:
> http://www.sunvolt.com/click-examples/exception.htm?actionLink=brokenBorderLink#
> I prefer earlier approach, as the error is explicit. The new approach
> logs an error message, but beyond that you would not have known that
> an error occured. The #writeForm() call is not even rendered, as is
> done with an invalid object reference.
> regards Malcolm Edgar
--
This message is automatically generated by JIRA.
-
If you think it was sent incorrectly contact one of the administrators: http://issues.apache.org/jira/secure/Administrators.jspa
-
For more information on JIRA, see: http://www.atlassian.com/software/jira
---------------------------------------------------------------------
To unsubscribe, e-mail: velocity-dev-unsubscribe@jakarta.apache.org
For additional commands, e-mail: velocity-dev-help@jakarta.apache.org