1) I think it's a GREAT idea to explain options for avoiding an exception in
the exception.
2)
I agree that there are 2 paradigms, the current (work as best as you can,
even if it is wrong) and what we are looking at as the new (fail loudly if
it isn't right).
and I understand the desire for backwards compatibility. and agree that
there should be a way to achieve it.
however, I would like to look this statement I bit closer.
I've personally got hundreds of templates in production and support users
with hundreds more. Say 5% of those templates have this error. (It's not
hard to make -- note that the Velocity test suite for Anakia contains this
error). All of a sudden I have tens of templates, scattered all over the
place that suddenly cause errors
In my mind this is a lot of proof the log files don't really work.
because if they did, the error's would go away. and without knowing how the
macro's work, it's hard to tell if the breaking is important, but I tend to
put parameters in a function because they are to be used, and therefore
would assume it would be important at least in some situations.
-------------------------------------------------------------------------------------
My point is this. As the Velocity community continues to grow, I would like
to avoid these things. I would like to make it easier to configure Velocity,
easier to make it work, easier to debug, so future code does not suffer the
same as the past. to this end, I once again push for the default settings
(because new users don't usually change those for a while) to throw errors
when you do something wrong. Error's that tell you
1) what went wrong
2) where it went wrong
3) what you tried.
4) what was possible ?
5) suggestions on how to fix it?
for example.
(not sure if this is still true in the latest version, as my working version
is a couple of versions behind)
if a template is not found in a #parse("template2") call, it is ignored.
so
123#parse("unknownTemplate.vm")567
will output -> 123567
better would be it throws and error ("unknownTemplate").
better still
unknow template line 1, col 4 in yourTemplate.vm
better still
unknow template 'unknownTemplate.vm'
line 1, col 4 in yourTemplate.vm
better still
couldn't find template 'unknownTemplate.vm'
at line 1, col 4 in yourTemplate.vm
from resource loaders:
file resource load [path = c:\code]
file resource load [path = c:\templatesss]
best
couldn't find template 'unknownTemplate.vm'
at line 1, col 4 in yourTemplate.vm
from resource loaders:
file resource load [path = c:\code]
file resource load [path = c:\templatesss]
To ignore this error set the parameter
'velocity.errors.ignoreUnknownTemplate' to false
-------------------------------------------------------------------------------------
These type of errors really help to make debugging easy (for example, i
would see here that i misspelled templates)
which makes the life a bit easier for us experienced users.
but can make a world of difference to a newbie, and that difference can be
the difference between continuing with the product, or just being
frustrated.
also the parameter being written lines away from the checking of the
parameter helps to ensure that it is correct (as opposed to documents
away in the manual or code example)
so anyways, that concludes my rant :-)
Llewellyn.
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
